Skip to main content
Glama

reassign

by app.reassign

Schedule into free time

schedule

Find conflict-free time and place one or more events — the easiest way to book work without computing slots yourself. (If you already know both an exact start AND end, use write_events create instead.) YOU resolve any relative phrasing ("tomorrow", "next monday", "this afternoon") into the structured fields; this tool does no date parsing. Pass requests, each with a name, duration ("90m", "1h30", "2h"), a date (ISO "YYYY-MM-DD"), and EITHER an exact start ("HH:MM", 24-hour) to place there, OR an earliest/latest ("HH:MM") window to search within (map "afternoon" → earliest "13:00", latest "18:00"), OR neither to search the whole working day. For each request: if exactly one conflict-free time fits it is created immediately with an undoToken; otherwise you get ranked options and a commitToken — call confirm_schedule to pick one (or set autoCommitBest: true on a flexible request to book the top pick in one shot and skip that round-trip). Requests are placed in order and kept off each other's committed slots. Each request may carry a request_id so retries don't double-book. If the user has a Google Calendar connected with a default sync calendar, a scheduled event is also pushed to Google, the same as a dial create. The response reports per-request results (each with its 0-based index).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
renderNoWhen the user is looking at their reassign dial, set true to repaint it with the updated day in this same call.
requestsYes

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining key behaviors: it does no date parsing (agent must resolve relative phrases), places requests in order, prevents overlaps, pushes to Google Calendar under certain conditions, and returns `undoToken`/`commitToken`/`options` per request. This adds substantial context beyond the minimal `readOnlyHint:false`/`destructiveHint:false`.

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?

Though long, it is dense and front-loaded with the purpose, then alternates usage rules, parameter semantics, and response notes. Every sentence contributes a distinct piece of operational guidance, 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?

Given no output schema, the description responsibly mentions the response shape (`results`, `undoToken`, `commitToken`, `options`) and the 0-based indices. It covers the main flows (immediate vs options, autoCommit, idempotency) and side-effects (Google sync), so an agent can invoke and interpret results confidently.

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?

The description explains the crucial parameter interactions: `start` vs `earliest`/`latest` vs none, gives concrete duration examples ('90m', '1h30'), maps relative phrases to times, and covers `request_id` idempotency and `autoCommitBest` behavior. However, it omits some parameters like `kind`, `recurrence`, and `render`, leaving that to schema descriptions, so it doesn't fully compensate for the 50% schema 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?

The verb+resource is explicit: 'Find conflict-free time and place one or more events', clearly indicating a scheduling/book-writing action. It also distinguishes itself from the sibling `write_events` for exact start/end, so the agent knows what makes this tool special.

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?

Explicitly positions itself as the alternative to hand-computing slots ('easiest way to book work without computing slots yourself') and points to `write_events create` when exact start and end are known. It also gives conditional guidance on `autoCommitBest` (one-shot routine bookings vs review-before-commit), providing clear when-to/when-not-to guidance.

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