amazing-marvin-complete-mcp

set_reminder

Instructions

Set an own reminder on a task, or a standalone reminder. With task_id the reminder is written in the app's form: an entry in the task's reminders list (reminderId of 13 characters, time in seconds) and a server entry of type M with taskId — the app shows it under Reminders and the notification arrives, and mark_done/delete_task clean it up. A clock time on a task is set with update_task(time=...). Without task_id a standalone server entry of type M is written (requires Marvin's mobile app for the notification).

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	Notification text (max 200 chars). Standalone: required. On a task: the task's title is used
`task_id`	No	The task's id: the reminder is added to the task in the app's form. Omit for a standalone reminder
`time_unix_seconds`	Yes	Unix time (seconds) for the reminder

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

removedInput schema / properties / reminder_id

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Custom ID; randomized otherwise. Do NOT use a task ID here — see description."
-}

addedInput schema / properties / task_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The task's id: the reminder is added to the task in the app's form. Omit for a standalone reminder"
+}

addedInput schema / properties / title / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / title / default
```
Added value: +null
```

changedInput schema / properties / title / description

Previous value: -"Text shown in the notification (max 200 chars)"New value: +"Notification text (max 200 chars). Standalone: required. On a task: the task's title is used"

removedInput schema / properties / title / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "title",
-  "time_unix_seconds"
-]New value: +[
+  "time_unix_seconds"
+]

First observedv1.3.0Aug 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the write/idempotent/safety profile; the description goes well beyond by disclosing the internal representation (task reminders list entry plus a type-M server entry), the cleanup behavior (mark_done/delete_task remove it), and a real operational constraint (standalone reminders require Marvin's mobile app for the notification). That is exactly the extra context annotations cannot express.

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 purpose, then the two modes in order. It is dense and includes some low-level implementation detail ('reminderId of 13 characters', 'type M') that is arguably noise for an agent, but it stays on one topic and every sentence carries routing or behavioral value.

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?

An output schema exists so return values need not be explained, and the annotations cover the safety profile. The description completes the picture with both invocation modes, the cleanup path, and the delivery limitation for standalone reminders, so an agent has everything needed to call it correctly.

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 100%, so the baseline is 3 and the schema already documents title/task_id/time_unix_seconds semantics. The description adds mode-dependent meaning beyond the schema, notably that standalone reminders need the mobile app for delivery, though most of the task_id/title split largely restates the schema text.

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 states a specific verb+resource ('Set a reminder') and immediately splits it into the two distinct modes it supports (on a task vs. standalone). It also names the sibling that handles the related clock-time case (update_task(time=...)), letting an agent distinguish it from update_task, get_reminders and delete_reminder without reading schemas.

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?

It gives explicit conditional guidance: 'With task_id...' versus 'Without task_id...', and explicitly redirects the clock-time-on-a-task case to update_task(time=...). This is a clear when-to-use / when-to-use-something-else routing that leaves nothing to inference.

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

Deploy Server