Skip to main content
Glama

Write events

write_events

Create, update (edit), move/reschedule, shift, reflect, or manage a block's checklist — bulk/batch, one or many in a single call. Pass ops, an array where each item has an op (create | update | move | shift | reflect | checklist) plus that op's fields; a single edit is just a 1-item array. Times are 24-hour HH:MM; for an event crossing midnight set endNextDay=true. reflect records how a PAST planned event actually went (kept | skipped | changed | added, with an optional actual time) — it never renames or re-times the plan; target one occurrence of a recurring event by its seriesId@YYYY-MM-DD id. checklist manages a block's microtasks: pass items to set/replace the ordered list (a template edit — whole series, or one occurrence with scope 'this'), or check/uncheck (by item id or exact text) to tick them off for a single occurrence; the current microtasks + each one's done state come back on a get_schedule read as the event's checklist. For a recurring event choose a scope: 'all' (default), 'future', or 'this' (the last two need occurrenceDate). To re-time an existing event use move (new start/date, duration kept) or shift (relative nudge by byMinutes); use update only to also rename, re-kind, re-area, or resize (change end). If you know the duration but not a conflict-free time (or only a rough window), use schedule instead of a create. By default the whole batch is atomic: if ANY op fails validation (e.g. a conflict), nothing is written and the failing ops are returned as errors — fix and resend. Pass partial: true for best-effort (apply what's valid). Ops apply in order as one transaction and are checked against each other: two creates can't double-book a slot, and an earlier move frees a slot a later op can reuse. Target each event id at most once per batch. Reference an area/activity type by id or by areaName/activityTypeName; create new ones first with manage_categories. If the user has a Google Calendar connected, creating or editing a calendar-linked event (or one created under their default sync calendar) also pushes the change to Google — the same as editing on the dial; don't edit an event get_schedule/find_event marked readOnly (it's from a calendar the user doesn't own and the change would silently revert). To remove events or clear a day use delete_events. The response reports applied, failed, skipped (validated but not written because the atomic batch was rejected), and per-op results (each with its 0-based index).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsYes
renderNoWhen the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. Otherwise the change reaches an open dial only if the host forwards this result.
conciseNoDrop the human-readable `suggestedFollowup` prose from the response (the structured `undoToken` is still returned). Saves tokens.
partialNoBest-effort mode: apply the ops that succeed and report the rest as errors, instead of the default all-or-nothing.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=false, openWorldHint=false, destructiveHint=false) so the description carries the full burden. It discloses atomicity (whole batch or nothing on failure), partial mode, ordering and conflict checking between ops, Google Calendar sync behavior, and that readOnly events will silently revert. These are critical behavioral traits beyond annotations.

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?

The description is long but densely packed with actionable information, well-structured with inline explanations of each op and use case. Every sentence adds value covering operational details, alternatives, and constraints. It front-loads the main ops before diving into specifics, making it easy to scan.

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?

The tool has 6 distinct operations, multiple modes, and complex interactions. The description covers all of them, including atomic vs partial, conflict checking, recurring event scope, Google sync, response structure (applied/failed/skipped/results), and the readOnly warning. Despite no output schema, it explains the response fields. It is complete for the tool's complexity.

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 75% and many parameters have descriptions. The description adds usage-level semantics: how ops array works, scope meanings, occurrenceDate usage, and specifics like 'endNextDay' and 'reflect' semantics. However, it doesn't describe every parameter exhaustively, but the schema already does; the description adds strategic guidance on when to use which fields.

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 clearly states the tool creates, updates, moves, shifts, reflects, and manages checklists for events, with explicit mention of bulk/batch capability. It distinguishes from sibling tools like delete_events and schedule by naming them and contrasting use cases (e.g., 'use schedule instead of a create' and 'To remove events... use delete_events').

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?

The description provides extensive when-to-use guidance: when to use move/shift vs update, when schedule is preferred, atomic vs partial behavior, and when to use delete_events. It explicitly states when not to edit readOnly events and how to handle conflicts. This is far beyond minimal guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct operation: reading (get_schedule, find_event, get_energy, get_weather, show_day), scheduling (schedule, confirm_schedule), event editing (write_events, delete_events), backlog management (manage_backlog), category management (manage_categories), reflection (review_day), undo, and feedback. The boundary between schedule and write_events is explicitly clear (exact times vs. conflict-free search), and get_schedule vs. show_day are differentiated by text vs. visual presentation. The only minor ambiguity is that manage_backlog includes a 'schedule' op, but that's internal to the tool.

Naming Consistency4/5

All but two tools follow verb_noun snake_case: confirm_schedule, delete_events, find_event, get_energy, get_schedule, get_weather, manage_backlog, manage_categories, review_day, send_feedback, show_day, write_events. The exceptions are 'schedule' and 'undo', which are bare verbs and thus slightly break the consistent pattern.

Tool Count5/5

14 tools is well-scoped for a comprehensive scheduling assistant: read surfaces, write surfaces, assisted scheduling, backlog/category management, reflection, undo, weather/energy, and feedback. Each tool covers a distinct capability, and none feels redundant. Only the extra weather and energy getters could arguably be merged with get_schedule, but they serve specific use cases.

Completeness5/5

The tool surface covers the full lifecycle: create (schedule, write_events), read (get_schedule, find_event), update (write_events, manage_backlog, manage_categories), delete (delete_events, review_day discard), plus undo and confirmation flows. There are no obvious dead ends or missing CRUD operations for the scheduling domain. Weather and energy are bonuses that support informed scheduling decisions.