Skip to main content
Glama
Sign In
Chronary

Chronary

Official
by Chronary
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_event

Schedule bookings, appointments, meetings, or holds on a calendar. Created events block agent availability and appear in availability queries; holds auto-expire.

Instructions

Create a booking, appointment, meeting, hold, or any scheduled event on a calendar. The calendar_id comes from create_calendar or list_events. Once created, this event blocks the agent's availability during that time and appears in availability queries. Use status="hold" with hold_expires_at to tentatively reserve a slot that auto-releases on TTL.

Input Schema

NameRequiredDescriptionDefault
titleYesEvent title
statusNoEvent status. "hold" creates a tentative reservation that auto-expires at hold_expires_at. Defaults to "confirmed".
all_dayNoWhether this is an all-day event
end_timeYesEnd time (ISO 8601)
remindersNoReminder offsets in minutes before start_time (e.g. [10, 1440]). Each fires an event.reminder webhook and shows as an alarm in the iCal feed. Omit or null to inherit the calendar default (then the system default of 10 min); [] for no reminders.
start_timeYesStart time (ISO 8601)
calendar_idYesCalendar ID to add the event to
descriptionNoOptional event description
hold_priorityNoOnly valid with status="hold". Higher-priority overlapping holds pre-empt lower-priority ones. Defaults to 0.
hold_expires_atNoRequired when status="hold". ISO 8601 timestamp 30s-15min in the future. Auto-releases the hold when reached.
recurrence_ruleNoMake this a recurring series (RFC 5545 RRULE subset, no "RRULE:" prefix), e.g. "FREQ=WEEKLY;BYDAY=MO,WE;COUNT=12". Supports FREQ=DAILY/WEEKLY/MONTHLY/YEARLY, INTERVAL, COUNT (max 730) or UNTIL, BYDAY (weekly list or monthly ordinal like 2TU/-1FR), BYMONTHDAY (1-28 or -1). start_time must match the rule pattern; expansion is UTC-only. Not allowed with status="hold". Free plan: max 5 recurring events, series must end within 90 days.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.3
    • changedInput schema / properties / end_time / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
    • changedInput schema / properties / hold_expires_at / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
    • changedInput schema / properties / start_time / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
  2. Changed1 schema field changedv1.4.1
    • addedInput schema / properties / recurrence_rule
      Added value: +{
+  "description": "Make this a recurring series (RFC 5545 RRULE subset, no \"RRULE:\" prefix), e.g. \"FREQ=WEEKLY;BYDAY=MO,WE;COUNT=12\". Supports FREQ=DAILY/WEEKLY/MONTHLY/YEARLY, INTERVAL, COUNT (max 730) or UNTIL, BYDAY (weekly list or monthly ordinal like 2TU/-1FR), BYMONTHDAY (1-28 or -1). start_time must match the rule pattern; expansion is UTC-only. Not allowed with status=\"hold\". Free plan: max 5 recurring events, series must end within 90 days.",
+  "maxLength": 256,
+  "type": "string"
+}
  3. First observedv1.2.5

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare write, non-idempotent, non-destructive. The description adds substantive behavior beyond that: the event blocks the agent's availability and surfaces in availability queries, and holds auto-release on their TTL. No auth or rate-limit detail, but the side-effect disclosure is the important part.

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 tight sentences, purpose front-loaded, followed by the sourcing constraint and then the hold pattern. Every sentence adds information with no filler.

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 an 11-parameter mutation tool with no output schema, the description covers purpose, key side effects, the hold workflow, and the source of the required calendar_id while the schema handles all field-level detail. Nothing essential to invoking it correctly is missing.

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 coverage is 100%, so the schema already documents all 11 parameters in depth (status, hold_priority, hold_expires_at, recurrence_rule, reminders). The description only reinforces the hold/TTL pairing and the calendar_id source, which the schema does not cover, so baseline 3 is right.

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 ('Create a booking, appointment, meeting, hold, or any scheduled event on a calendar') and enumerates the concrete use cases it covers. An agent can immediately distinguish this from siblings like create_calendar, update_event, or create_proposal.

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?

Gives clear context for the hold workflow ('Use status="hold" with hold_expires_at to tentatively reserve a slot') and tells the agent where calendar_id originates (create_calendar or list_events). It does not, however, state exclusions or when to prefer confirm_event/release_event/update_event over creating.

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

Deploy Server

Other Tools