TimeTree MCP Server

copy_event

Copies an existing event to a new date and time, optionally into another calendar, and returns the new single event while leaving the original unchanged.

Instructions

Copy an existing event to a new date and time, optionally into another calendar, and return the new event. Keeps the title, note, location, URL, label, reminders, and checklist; recurrence is not copied, so the copy is a single event. Attendees and virtual attendees are kept only within the same calendar. The original is unchanged.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	Title of the copy (default: the original title)
`end_at`	No	End time of the copy as Unix timestamp in milliseconds (default: same length as the original)
`start_at`	Yes	Start time of the copy as Unix timestamp in milliseconds
`event_uuid`	Yes	The UUID of the event to copy (from get_events)
`calendar_id`	Yes	The calendar ID from list_calendars (numeric string; numbers are also accepted)
`target_calendar_id`	No	Calendar ID from list_calendars to copy into (default: the same calendar)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`event`	Yes
`message`	No
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Oct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing which fields carry over (title, note, location, URL, label, reminders, checklist), that recurrence is not copied so the result is a single event, that attendees and virtual attendees only carry within the same calendar, and that the original is unchanged. This is exactly the kind of edge-case detail an agent needs for a non-idempotent, open-world write tool.

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?

Three sentences, front-loaded with the core action, followed by copied-field semantics and edge cases. No filler and no repetition of the name or title.

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 the description needn't explain the return shape, and it doesn't. It covers the behaviors that matter for correct invocation – recurrence dropping, attendee scoping, source immutability – leaving nothing an agent would need to guess.

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%, so parameter meaning is already documented. The description reinforces the calendar_id vs target_calendar_id distinction ('optionally into another calendar') and implies default behaviors, but adds no syntax or constraints beyond the schema baseline.

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 and resource ('Copy an existing event to a new date and time, optionally into another calendar') plus the return value. It is clearly distinguishable from create_event and update_event siblings because it copies existing state rather than creating from scratch or mutating in place.

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?

The scenario (duplicating an event to a new date/time, possibly into another calendar) is stated clearly, giving a strong implied when-to-use. It does not name alternatives like create_event or state exclusions, which keeps it just below a 5.

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