Local MCP

Update Reminder

update_reminder

Destructive

Updates an existing reminder in Reminders.app. Change the title, due date, notes, priority, make it repeat or stop repeating (recurrence), or move it to another list (list_name). Get reminder_id from list_reminders. IMPORTANT: moving to a list in a DIFFERENT account (e.g. iCloud ↔ Exchange) recreates the reminder, so its id changes — the response then has id_changed: true, the new id in reminder_id and the dead one in previous_reminder_id. Always take reminder_id from the response before any follow-up call.

Input Schema

Name	Required	Description
`notes`	No	New notes text (optional)
`title`	No	New title (optional)
`confirm`	No	Ignored; kept for older clients.
`due_date`	No	New ISO 8601 due date. Pass empty string to clear (optional)
`priority`	No	Priority: none \| low \| medium \| high (optional)
`list_name`	No	Move the reminder to this list (a name from get_reminder_folders) (optional). Moving to a list in ANOTHER account recreates the reminder and CHANGES its id — read the new one from reminder_id in the response (id_changed: true).
`recurrence`	No	Make it a repeating reminder: 'daily', 'weekly', 'monthly', or 'yearly' ('none' stops an existing repetition; omit to leave it as it is). A repeating reminder needs a due date.
`reminder_id`	Yes	Reminder identifier from list_reminders
`recurrence_count`	No	Total number of occurrences (optional). Mutually exclusive with recurrence_until; if neither is given it repeats indefinitely. Needs recurrence.
`recurrence_until`	No	ISO 8601 date the repetition stops on (optional; takes precedence over recurrence_count). Needs recurrence.
`recurrence_interval`	No	Repeat every N periods (optional, default 1 — e.g. recurrence='weekly' + recurrence_interval=2 = every 2 weeks). Needs recurrence.

Output Schema

Name	Required	Description
`list`	No	Destination list, when the update moved the reminder.
`note`	No
`title`	No
`updated`	No
`id_changed`	No	true when the update recreated the reminder (a move across accounts), which invalidates the id you passed in.
`reminder_id`	No	The reminder's id AFTER the update — use this one from now on.
`previous_reminder_id`	No	Only when id_changed: the id you passed in, which no longer exists.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / confirm / description

Previous value: -"Must be true to apply changes"New value: +"Ignored; kept for older clients."

Changed4 schema fields changedOct 22, 2026

addedInput schema / properties / recurrence

Added value: +{
+  "description": "Make it a repeating reminder: 'daily', 'weekly', 'monthly', or 'yearly' ('none' stops an existing repetition; omit to leave it as it is). A repeating reminder needs a due date.",
+  "enum": [
+    "daily",
+    "weekly",
+    "monthly",
+    "yearly",
+    "none"
+  ],
+  "type": "string"
+}

addedInput schema / properties / recurrence_count

Added value: +{
+  "description": "Total number of occurrences (optional). Mutually exclusive with recurrence_until; if neither is given it repeats indefinitely. Needs recurrence.",
+  "type": "integer"
+}

addedInput schema / properties / recurrence_interval

Added value: +{
+  "description": "Repeat every N periods (optional, default 1 — e.g. recurrence='weekly' + recurrence_interval=2 = every 2 weeks). Needs recurrence.",
+  "type": "integer"
+}

addedInput schema / properties / recurrence_until

Added value: +{
+  "description": "ISO 8601 date the repetition stops on (optional; takes precedence over recurrence_count). Needs recurrence.",
+  "type": "string"
+}

Changed2 schema fields changedAug 26, 2026

changedInput schema / properties / list_name / description

Previous value: -"Move the reminder to this list (a name from get_reminder_folders) (optional)"New value: +"Move the reminder to this list (a name from get_reminder_folders) (optional). Moving to a list in ANOTHER account recreates the reminder and CHANGES its id — read the new one from reminder_id in the response (id_changed: true)."

addedOutput schema / properties

Added value: +{
+  "id_changed": {
+    "description": "true when the update recreated the reminder (a move across accounts), which invalidates the id you passed in.",
+    "type": "boolean"
+  },
+  "list": {
+    "description": "Destination list, when the update moved the reminder.",
+    "type": "string"
+  },
+  "note": {
+    "type": "string"
+  },
+  "previous_reminder_id": {
+    "description": "Only when id_changed: the id you passed in, which no longer exists.",
+    "type": "string"
+  },
+  "reminder_id": {
+    "description": "The reminder's id AFTER the update — use this one from now on.",
+    "type": "string"
+  },
+  "title": {
+    "type": "string"
+  },
+  "updated": {
+    "type": "boolean"
+  }
+}

Changed1 schema field changedAug 2, 2026

changedInput schema / properties / list_name / description

Previous value: -"Move the reminder to this list (a name from list_reminder_lists) (optional)"New value: +"Move the reminder to this list (a name from get_reminder_folders) (optional)"

First observedJun 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Even with destructiveHint=true already disclosed by annotations, the description adds crucial behavioral context: moving to a list in a different account recreates the reminder and changes its id, with the response indicating id_changed, reminder_id, and previous_reminder_id. It further instructs the agent to use the new id before follow-up calls, which is exactly the kind of side-effect transparency a mutation tool needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description front-loads the core update purpose, then lists editable fields, then gives the id precondition and the critical cross-account caveat. Every sentence contributes useful information, and the IMPORTANT marker appropriately highlights the highest-risk behavior.

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 mutation tool with 11 parameters, this description is complete enough alongside a 100%-covered schema, destructive annotations, and an output schema. It covers what can be changed, where the id comes from, and the major hidden side effect of cross-account moves, so an agent has what it needs to call it correctly.

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 100%, and the schema already documents optionality, enums, defaults, and mutual exclusivity for recurrence parameters. The description adds useful context for reminder_id sourcing and the list_name id-change behavior, but most field-level semantics are already carried by the schema, so the baseline of 3 is appropriate.

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 and resource ('Updates an existing reminder in Reminders.app') and enumerates the editable fields, making clear it is an update operation rather than create/delete/complete. It also names the sibling source for the required id ('Get reminder_id from list_reminders'), which helps distinguish it from related reminder tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear precondition for use: the reminder must already exist and reminder_id comes from list_reminders. It also gives an important exception for cross-account list moves. However, it does not explicitly contrast this tool with create_reminder or complete_reminder, so the when-not-to-use guidance is implied rather than stated.

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

All Local MCP 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.