Local MCP

Update Reminder

update_reminder

Destructive

Updates an existing reminder in Reminders.app. Change the title, due date, notes, priority, or move it to another list (list_name). Get reminder_id from list_reminders. Requires confirm=true. 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

TableJSON Schema

Name	Required	Description
`notes`	No	New notes text (optional)
`title`	No	New title (optional)
`confirm`	No	Must be true to apply changes
`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).
`reminder_id`	Yes	Reminder identifier from list_reminders

Output Schema

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

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.6/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true, but the description adds genuinely irreplaceable behavior: cross-account list moves recreate the reminder and change its id, with id_changed:true and previous_reminder_id surfaced in the response. This is exactly the kind of non-obvious side effect the agent must know before a follow-up call.

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 core action, then narrows to fields, prerequisites, and the id-change warning. Slightly dense, but each sentence earns its place and the IMPORTANT callout is well placed.

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?

Despite an output schema existing, the description proactively explains the one response field (id_changed) that changes the caller's next move, plus prerequisites and side effects. Nothing needed to invoke or chain this tool is missing.

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, but the description adds real meaning beyond the schema: the provenance of reminder_id, the account-boundary semantics of list_name, and the response contract for id changes. It stops short of explaining due_date clearing or priority defaults, which the schema already covers.

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?

States a specific verb (updates) and resource (an existing reminder in Reminders.app) and enumerates the mutable fields, distinguishing it clearly from create_reminder/delete_reminder siblings. An agent can identify the tool's scope 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 Guidelines4/5

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

Provides concrete prerequisites: get reminder_id from list_reminders, list names from get_reminder_folders, and confirm=true required. It does not explicitly contrast with alternatives like create_reminder, but the routing context is clear enough to invoke correctly.

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.