Aimgod

Change a task

update_task

Destructive

Change one task when the user asks: rename, move to another date, set or clear the time, mark done or not done, star, set the sphere or description, set or remove the reminder (null removes it), set, change or stop the repeat. Send only what changes. On a repeating task the name, description, time and reminder change for the whole series from this day on; subtasks are each day's own. Repeating tasks are habits with statistics: when moving several tasks ("move everything to tomorrow") move only one-off tasks; move a repeating task only when the user names it, and only to a day its habit does not have yet (a daily habit already has tomorrow, so leave it and tell the user).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>"
    },
    "name": "update_task"
  }
}

Input Schema

Name	Required	Description
`date`	No	YYYY-MM-DD
`done`	No
`note`	No	One line every member of a shared sphere sees under the title: on the person's own task, or alone on a task of a sphere where they are responsible. null clears it.
`time`	No	24h HH:MM, empty string removes the time
`title`	No
`repeat`	No	Repeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly. Days are created 60 days ahead, each one a task of its own. Set on a day in the middle of a series, the new rule starts from that day and earlier days keep the old one. null stops the repeat: open days after today go, done days stay.
`sphere`	No	Sphere name or id, empty string removes it
`starred`	No
`task_id`	Yes
`description`	No
`remind_minutes_before`	No	Remind this many minutes before the task's time: 5, 15, 30, 60, 120 (2 hours), 1440 (1 day) or 10080 (1 week). Only for a task with a time. null removes it. On a repeating task it changes for the whole series.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / remind_minutes_before / description

Previous value: -"Remind this many minutes before the task's time: 5, 15, 30, 60, 120 (2 hours), 1440 (1 day) or 10080 (1 week). Only for a task with a time. null removes it. On a repeating task it changes this day only."New value: +"Remind this many minutes before the task's time: 5, 15, 30, 60, 120 (2 hours), 1440 (1 day) or 10080 (1 week). Only for a task with a time. null removes it. On a repeating task it changes for the whole series."

Changed2 schema fields changedOct 20, 2026

changedInput schema / properties / repeat / anyOf

Previous value: -[
-  {
-    "description": "Repeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly, or days:mon,wed,fri for chosen weekdays (only when custom days are switched on in Aimgod). Days are created 60 days ahead, each one a task of its own.",
-    "pattern": "^(daily|weekly|weekdays|weekends|monthly|yearly|days:[a-z,]{3,27})$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Repeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly. Days are created 60 days ahead, each one a task of its own.",
+    "pattern": "^(daily|weekly|weekdays|weekends|monthly|yearly)$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / repeat / description

Previous value: -"Repeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly, or days:mon,wed,fri for chosen weekdays (only when custom days are switched on in Aimgod). Days are created 60 days ahead, each one a task of its own. Set on a day in the middle of a series, the new rule starts from that day and earlier days keep the old one. null stops the repeat: open days after today go, done days stay."New value: +"Repeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly. Days are created 60 days ahead, each one a task of its own. Set on a day in the middle of a series, the new rule starts from that day and earlier days keep the old one. null stops the repeat: open days after today go, done days stay."

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / note

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 140,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "One line every member of a shared sphere sees under the title: on the person's own task, or alone on a task of a sphere where they are responsible. null clears it."
+}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / repeat

Added value: +{
+  "anyOf": [
+    {
+      "description": "Repeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly, or days:mon,wed,fri for chosen weekdays (only when custom days are switched on in Aimgod). Days are created 60 days ahead, each one a task of its own.",
+      "pattern": "^(daily|weekly|weekdays|weekends|monthly|yearly|days:[a-z,]{3,27})$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Repeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly, or days:mon,wed,fri for chosen weekdays (only when custom days are switched on in Aimgod). Days are created 60 days ahead, each one a task of its own. Set on a day in the middle of a series, the new rule starts from that day and earlier days keep the old one. null stops the repeat: open days after today go, done days stay."
+}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / remind_minutes_before

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        5,
+        15,
+        30,
+        60,
+        120,
+        1440,
+        10080
+      ],
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Remind this many minutes before the task's time: 5, 15, 30, 60, 120 (2 hours), 1440 (1 day) or 10080 (1 week). Only for a task with a time. null removes it. On a repeating task it changes this day only."
+}

First observedOct 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only flag destructive=true and non-idempotent; the description goes well beyond by explaining what actually gets destroyed ('open days after today go, done days stay'), how repeat changes propagate from a mid-series day, and how habits differ from one-off tasks. This is exactly the context an agent needs before a destructive edit.

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 with the verb and the user-intent trigger, and every clause carries behavioral information, so little is wasted. The final two sentences are long and clause-dense, making it harder to scan than it needs to be.

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?

For an 11-parameter mutation tool with no output schema and mid-range schema coverage, the description covers partial-update semantics, per-field scope, and series side effects thoroughly. It is silent on the return value and on error/precondition behavior, a minor omission given no output schema exists.

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 only 55%, but the description supplies the semantics the schema omits: partial-update contract ('Send only what changes'), null-removes for reminder, empty-string-removes for time/sphere, and per-field series scope (name/description/time/reminder apply to the whole series, subtasks are per-day). Task_id remains undocumented, which is the main residual gap.

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?

States a specific verb and resource ('Change one task') and then enumerates every mutation the tool supports (rename, move, time, done, star, sphere, description, reminder, repeat), which cleanly separates it from add_task and update_subtask in the sibling list.

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?

Explicitly says when to use it ('when the user asks: rename, move to another date...') and adds the crucial when-not rule for repeating tasks: in bulk moves only one-off tasks, move a habit only when the user names it and only to a day it lacks, otherwise leave it and tell the user.

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

All Aimgod tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.