Skip to main content
Glama

Duplicate event

duplicate_event

Copies an event's title, description, location, theme, questionnaire, and RSVP settings to a new date without guests or messages, creating an uninvited duplicate for hosts only.

Instructions

Copy an event with its settings to a new date. The copy has no guests yet.

Makes a copy as Duplicate on the event page does: title, description, location, theme, questionnaire and RSVP settings, no guests and no messages. The copy starts at start_at and keeps the original's length; Partiful does not copy the RSVP deadline. Nobody is invited. Returns the new event. Hosts only.

Input Schema

NameRequiredDescriptionDefault
titleNoTitle of the copy. Default: the same.
event_idYesevent_id from list_events.
start_atYesStart of the copy, ISO 8601. Without an offset it is read in the event's time zone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the mutation annotations, it discloses exactly what is copied (title, description, location, theme, questionnaire, RSVP settings), what is omitted (guests, messages, RSVP deadline), that length is preserved, that nobody is invited, and that it returns the new event. It does not contradict any annotations.

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?

The description is front-loaded and appropriately detailed. It is slightly repetitive about guests and invitations—'no guests yet,' 'no guests and no messages,' and 'Nobody is invited'—but the repetition does add emphasis to an important constraint.

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?

Given the mutation, lack of output schema, and simple parameter set, the description is complete: it covers source event selection, copied fields, omitted fields, resulting event, host restriction, and return value.

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 schema already explains the three parameters. The description adds useful behavioral meaning for start_at by noting that the copy keeps the original's length and that the RSVP deadline is not copied.

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: copy an event to a new date. It clearly scopes what is copied and what is not (settings yes, guests/messages no), which distinguishes it from create_event, update_event, and delete_event.

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 gives clear context that this is for duplicating an existing event with its settings, in contrast to creating from scratch. It also states the 'Hosts only' prerequisite, though it does not explicitly name alternative sibling tools or exclusion cases.

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