Skip to main content
Glama

reassign

by app.reassign

Delete events

delete_events
Destructive

Delete events or clear whole days — bulk/batch, one or many in a single call. Pass ops, an array where each item has an op (delete | clear): delete removes one event by id (for a recurring event set scope 'all' (default) / 'future' / 'this' with occurrenceDate); clear removes everything on a day (or a date..to range). By default the whole batch is atomic: if ANY op fails, nothing is removed; pass partial: true for best-effort. Every removal is reversible — the response returns an undoToken (call undo within 30 minutes). If the user has a Google Calendar connected, deleting a calendar-linked event also removes it from Google — the same as deleting on the dial; an event get_schedule/find_event marks readOnly is from a calendar the user doesn't own and can't be deleted this way. It reports applied, failed, skipped, and per-op results (each with its 0-based index). To create or edit events use write_events.

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.7/5.0
Behavior5/5

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

Annotations provide destructiveHint=true and readOnlyHint=false, and the description adds substantial behavior beyond this: atomic batch semantics by default, partial:true for best-effort, reversibility via undoToken within 30 min, Google Calendar propagation side-effects, and the readOnly detection mechanism. It also discloses return structure (applied/failed/skipped/results). No contradiction with 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?

Dense but well-organized single paragraph covering operations, variants, atomicity, reversibility, calendar caveats, and return format. Every sentence conveys meaningful guidance, but the paragraph is long; front-loading purpose and op structure is good, with behavioral caveats at the end. Could benefit from slight structural splitting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a destructive mutation tool with good annotations and detailed schema (75% coverage). Covers atomic behavior, undo, Google Calendar integration, recurring scope, readOnly limitation, and return format. No output schema, so it accurately describes what results to expect. The 4-param schema with 1 required makes this sufficient.

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 the description compensates for the uncovered quarter by explaining the ops array structure, op variants (delete/clear), recurring scope values ('all'/'future'/'this') with occurrenceDate, and date ranges. It clarifies partial, render, and the batch semantics of ops. Some param details (concise) are left to schema descriptions, which is acceptable given high coverage.

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?

Description states a specific verb+resource ('Delete events or clear whole days') and clearly distinguishes delete vs clear operations. It differentiates from sibling write_events (create/edit), undo (reversal), and find_event/get_schedule (read/localization). Scope handling for recurring events and Google Calendar caveats make purpose unmistakable.

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?

Provides explicit when-not guidance: readOnly events from non-owned calendars 'can't be deleted this way', and directs creation/editing to write_events. Explains partial vs atomic modes, recurring-event scope options, and undo availability window with a clear 30-minute window. Also names sibling tools get_schedule/find_event for context on readOnly detection.

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

All reassign toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources