Skip to main content
Glama

calendar_move_event

Idempotent

Move an iCloud calendar event to another calendar, keeping its uid, time, place, alarms, notes and guests. Use it to re-file an event, not to reschedule or delete it.

Instructions

Move an event to another of the owner's calendars, a repeating one as a whole series, keeping its uid, times, place, alarms, notes and guests.

Use when: the owner wants an event filed under a different calendar, e.g. from 'Calendar' to 'Work'. Not for changing its time or details (use calendar_update_event) or for removing it (use calendar_delete_event); never delete and recreate an event to move it. Parameters:

  • uid: the opaque uid string from calendar_list_events or a calendar_create_event result, copied exactly. A series moves as a whole; one date alone cannot be moved.

  • to_calendar: a name (any case) or id from calendar_list_calendars. An unknown value fails with "No calendar named ..." plus the valid names.

  • calendar: where the event is now, only to narrow the lookup. Naming the wrong one fails with "No event with uid" instead of searching further. Behavior:

  • iCloud relocates the stored event, so nothing is recreated, the uid stays and guests get no new invitation.

  • An event with guests is refused unless the server allows calendar invites (ALLOW_CALENDAR_INVITES), as for edits.

  • On a server without WebDAV MOVE it copies first and deletes the original after, removing the copy again if that delete fails, so the event never ends up in two calendars.

  • Moving to the calendar it is already in changes nothing, so a repeat is safe. Returns: {moved: true, uid, summary, from, to}, or {moved: false, uid, summary, calendar, note} when it was already there. Errors (in every case nothing was moved):

  • "No event with uid": list events again.

  • an unknown calendar: the message lists valid names.

  • "Blocked: ... ALLOW_CALENDAR_INVITES=false": ask the owner to move it in the Calendar app.

  • the target already holds an event stored under the same name, or the server refused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesEvent uid (from calendar_list_events).
calendarNoCalendar name (calendar_list_calendars); omit for all.
to_calendarYesThe calendar to move it to, by name from calendar_list_calendars (e.g. 'Personal', 'Work', 'Health').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "calendar_move_eventDictOutput",
      -  "type": "object"
      -}New value: +null
  2. Addedv0.7.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (idempotent, non-destructive, closed-world), and the description goes well beyond them: the ALLOW_CALENDAR_INVITES gate for events with guests, the WebDAV-MOVE-absent copy-then-delete-with-rollback path that guarantees the event is never in two calendars, and the no-op when the target equals the current calendar. This is exactly the extra context the annotations cannot carry.

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 purpose then usage, and uses clear Parameters/Behavior/Returns/Errors sections with no wasted filler. It is long, but with no output schema the Returns and Errors blocks are load-bearing rather than padding.

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 move tool with no output schema and no annotations on failure modes, the description supplies the exact return shapes ({moved:true,...} and already-there variant) and enumerates every error path with recovery guidance, leaving nothing an agent needs 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 already 100%, so baseline is 3, but the description adds real meaning: uid must be copied exactly and a series cannot be narrowed to one date; to_calendar accepts any case or id and fails with a message listing valid names; calendar is only a lookup-narrowing filter that fails loudly if wrong. This is useful semantics beyond the schema.

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+resource (move an event to another calendar) with precise scope: whole series, preserving uid, times, place, alarms, notes, guests. It also names the sibling tools it is not (calendar_update_event, calendar_delete_event), so an agent can distinguish it without opening any 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?

An explicit 'Use when' clause gives the triggering intent ('filed under a different calendar'), and explicit exclusions route time/detail changes to calendar_update_event and removals to calendar_delete_event. It even warns against the anti-pattern of delete-and-recreate to move an event.

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