amazing-marvin-complete-mcp

set_reminder

Schedule a standalone push reminder with a title and Unix timestamp, for non-task use only to prevent inconsistent server-side entries.

Instructions

Set a standalone push reminder (type 'M', requires the Marvin mobile app to be logged in). WARNING — data integrity: a task reminder in Marvin consists of TWO writes that only the app keeps in sync — reminder fields on the task document itself (taskTime, reminderTime, reminderOffset, snooze, autoSnooze) AND a server-side entry via /reminder/set. This tool only writes the server-side entry. Setting reminder_id to a task ID therefore does NOT link the reminder to the task in the app's UI, and risks an orphaned/inconsistent server-side entry (only visible through get_reminders). Task-linked reminders are set in the Marvin app; use this tool for standalone reminders only. Facts about time on tasks (live data 2026-09-02): the Time field in the app (taskTime) is a clock time that — with auto-created reminders enabled in the user's settings — automatically becomes a reminder at the same time (reminderTime = the clock time, offset 0); Time and reminder are in practice the same thing there. That this MCP does not set times on tasks is therefore an MCP limitation, never a Marvin limitation.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	Yes	Text shown in the notification (max 200 chars)
`reminder_id`	No	Custom ID; randomized otherwise. Do NOT use a task ID here — see description.
`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.

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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false): it discloses that a Marvin reminder is normally TWO writes, that this tool performs only the server-side /reminder/set write, and that using a task ID risks an orphaned entry 'only visible through get_reminders'. The app-login prerequisite and the practical limitation about taskTime/autoSnooze are also surfaced. No annotation contradiction.

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-loads the WARNING and the standalone-only rule before the explanatory detail, which is the right ordering. The trailing 'Facts about time on tasks' paragraph is somewhat tangential to invoking this tool, though it does justify the stated MCP limitation; the definition is long but most sentences earn their place.

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?

For a write tool with real data-integrity hazards, a 3-param schema at 100% coverage, an output schema, and partial annotation coverage, the description supplies the missing pieces: integrity semantics, prerequisites, safe-use boundary, and the task-reminder limitation. An agent can call this correctly and know when not to.

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; the description adds reason-level meaning for reminder_id (why a task ID is dangerous) and clarifies what the reminder represents. It stops short of stating any format details beyond the schema, but the added semantic context for the risky parameter is real value.

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 first clause states a specific verb+resource ('Set a standalone push reminder') and immediately scopes it as type 'M' requiring the mobile app. It explicitly distinguishes this from task-linked reminders, which is the exact confusion an agent would otherwise have.

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?

Gives an explicit when-to-use ('use this tool for standalone reminders only') and a when-not-to-use ('Task-linked reminders are set in the Marvin app'), plus a concrete parameter-level exclusion ('Setting reminder_id to a task ID therefore does NOT link the reminder'). Alternative routing is fully specified.

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