Skip to main content
Glama
Sign In

Aimgod

by io.github.sendziuk
OverviewDiscussionsAdmin

Add a task

add_task

Add one task to a day when the user asks to add or plan something. Without date it goes to today; without time it joins the untimed list. remind_minutes_before sets a reminder (the task needs a time). repeat makes it a repeating task (a habit): one call, Aimgod puts it on the following days itself, so do not add copies to several dates. sphere may be a shared sphere where the user is responsible (shared.my_role in list_spheres): the task goes to the whole sphere as its owner's, without starred, reminder or repeat; members and viewers cannot add there. If two spheres share a name, pass the id: a name picks the user's own.

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": {
      "title": "<title>"
    },
    "name": "add_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD
timeNo24h HH:MM, empty string removes the time
titleYes
repeatNoRepeat rule: daily, weekdays, weekends, weekly (same weekday), monthly, yearly. Days are created 60 days ahead, each one a task of its own.
sphereNoSphere name (case-insensitive) or id
starredNo
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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."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."
    • changedInput schema / properties / repeat / pattern
      Previous value: -"^(daily|weekly|weekdays|weekends|monthly|yearly|days:[a-z,]{3,27})$"New value: +"^(daily|weekly|weekdays|weekends|monthly|yearly)$"
  2. Changed1 schema field changed
    • addedInput schema / properties / repeat
      Added 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"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / remind_minutes_before
      Added value: +{
+  "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.",
+  "enum": [
+    5,
+    15,
+    30,
+    60,
+    120,
+    1440,
+    10080
+  ],
+  "type": "integer"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnly=false, destructive=false, idempotent=false, openWorld=false. The description then adds real behavior: default date is today, default time means untimed list, reminders require a time, repeat auto-creates tasks on following days (reducing duplicate-add risk), and shared-sphere ownership semantics. This is meaningful context beyond structured fields.

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 core action and trigger, then layered constraints. It is a dense single block (~90 words) with some clause stacking, but essentially every sentence adds distinct rules 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?

Covers defaults, permissions, repeat duplication and sphere resolution — the high-risk parts of an 8-param mutation tool with no output schema. It doesn't say what the call returns (e.g., the created task id) or error behavior on validation failure, which is the remaining gap.

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 63%, and the description fills the gap for the ambiguous ones: date fallback, time fallback, remind_minutes_before needing a time, repeat expansion, and sphere name-vs-id resolution. 'starred' and 'description' are left to the schema, which is acceptable given they are self-explanatory.

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 concrete verb+resource ('Add one task to a day') and the trigger ('when the user asks to add or plan something'), which distinguishes it from add_subtask and add_focus_point siblings. The scope is precise enough that an agent can select it without opening the 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?

Explicitly says when to use it and delivers exclusions: for repeat, 'do not add copies to several dates'; for shared spheres, 'members and viewers cannot add there'; for duplicate sphere names, 'pass the id'. Alternatives and prohibitions are named, not inferred.

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
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.

Resources