Skip to main content
Glama

Aimgod

by io.github.sendziuk
OverviewDiscussionsAdmin

Change a task

update_task

Change a task: 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 (remind_minutes_before, null removes it), set, change or stop the repeat. Send only what changes. Repeating tasks are habits with statistics: when moving several tasks ("move everything to tomorrow", "lighten my day") 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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoYYYY-MM-DD
doneNo
noteNoOne 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.
timeNo24h HH:MM, empty string removes the time
titleNo
repeatNoRepeat 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.
sphereNoSphere name or id, empty string removes it
starredNo
task_idYes
descriptionNo
remind_minutes_beforeNoRemind 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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."
  2. Changed1 schema field changed
    • 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."
+}
  3. Changed1 schema field changed
    • 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."
+}
  4. Changed1 schema field changed
    • 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."
+}
  5. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description adds substantial behavior the annotations cannot convey. It discloses null-as-removal for the reminder, the habit/statistics model behind repeating tasks, the 60-day-ahead materialization of repeat days, and the consequence of clearing a repeat (open days after today are deleted, done days remain) — real data-loss context. It also notes that a reminder change on a repeating task affects only that day.

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 correctly: the operation and its field list come first, conditional guidance second. Every sentence earns its place, though the final sentence is dense enough with parenthetical examples that it reads as two rules packed into one, slightly hurting scannability.

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, the description covers partial-update semantics, null-as-delete conventions, and the tricky habit side effects, which is the bulk of what an agent needs. It stops short of error behavior (invalid task_id), permission or shared-sphere authorization requirements, and what the call returns.

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 55%, so the description should carry more weight than a baseline 3. It names the fields that lack schema descriptions (done, starred, title, description) but adds no semantics beyond the names, and the two richest behaviors it explains (null removes the reminder; repeat clears future open days) are already spelled out in the schema. It compensates only partially for the coverage gap.

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 clause gives a precise verb and resource ('Change a task') and then enumerates the mutable surface (title, date, time, done, starred, sphere, description, reminder, repeat), so an agent knows exactly what the tool touches. It does not explicitly differentiate itself from the sibling update_subtask or from add_task/delete_task, which keeps it short of a 5.

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?

'Send only what changes' states the partial-update contract that selects this tool over a replace-style update. The final sentence gives explicit when/when-not rules for repeating tasks: bulk moves ('move everything to tomorrow') must skip habits, a repeating task moves only when the user names it, and only to a day the habit lacks, with instructions to leave it and tell the user otherwise.

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

All Aimgod toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources