reassign

Get schedule

get_schedule

Read-only

Read the calendar — the day's agenda, what's on, how busy you are, your availability, an overview of a day or week, where your time goes. Returns, in one call, everything needed to reason about the plan: the current time (now), the user's areas and activityTypes, userPreferences, and a days array (each day's events, free slots, and how its time splits across areas/types — blocking load and any non-blocking overlay load reported separately). Call it before scheduling to anchor relative times ('this afternoon'). Defaults to today; pass date for another single day, from+to for an inclusive range, or dates for a specific set (ISO YYYY-MM-DD). Pass compact: true to shrink events for wide ranges, or includeSeries: true to also get recurring masters as series. Each event carries its source ("reassign", else a provider like "google") and, when calendar-linked, its calendar name; an event with readOnly: true is on a calendar the user doesn't own — don't edit or delete it (tell them to change it there). kind is omitted for a normal blocking event; "non-blocking" is an overlay that may overlap others (fasting, an away marker); "reference" is see-only — its hours stay free, don't move/delete/schedule work into it unless asked. A confirmed past day carries a review adherence rollup plus per-event reflect actuals (an unreviewed day has neither) — use it for how a day or week actually went. When a calendar is connected, integrations describes it (connected sources + their calendars, classification fallbacks, and the default sync target); omitted otherwise. For a single day, a one-line weather headline is included when the user has a city — call get_weather only for hourly detail. backlogCount reports how many Inbox blocks (the Inbox of un-timed intentions) the user has; pass includeBacklog: true for the items (top of tray first, up to 50) or backlogQuery to find one by name — place/manage them with manage_backlog. Times are in the user's timezone; an untitled event shows as "(untitled)".

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No
`date`	No
`from`	No
`dates`	No
`compact`	No
`backlogQuery`	No	Filter the Inbox blocks by name (fuzzy, case/accent-insensitive) — e.g. "dentist". Implies includeBacklog; use it to FIND a specific Inbox block by name instead of paging the whole Inbox.
`includeSeries`	No
`includeBacklog`	No	Include the Inbox items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their Inbox.
`backlogPlannedOn`	No	Filter the Inbox blocks to those PLANNED for this day (a block's planned day, or a planned window covering it) — e.g. today's date to answer "what did I plan to get to today?". Implies includeBacklog; composes with backlogQuery. Overdue blocks carry `overdue: true` on the unfiltered read instead.

TDQS

A4.9/5.0

Behavior5/5

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

Despite readOnlyHint=true and openWorldHint=false annotations, the description adds extensive behavioral context: readOnly events must not be edited/deleted, 'non-blocking' and 'reference' semantics, review data only on confirmed past days, weather only when a city exists, timezone caveats, and conditional output fields. This far exceeds annotation coverage and warns about side effects (or their absence).

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 a single dense paragraph of about 300 words. It is front-loaded with the core purpose ('Read the calendar') and every sentence adds information, but it lacks bullet points or subheadings, making it less scannable than it could be. It is not concise, yet there is no fluff.

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?

With no output schema, the description fully specifies the return structure: now, areas, activityTypes, userPreferences, days array, per-day events/free slots, time splits, source, calendar, kind, review/reflect, integrations, weather, backlogCount, series, etc. It also covers edge cases (untitled events, unreviewed days) making it complete for a complex read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%, but the description compensates richly: it explains date defaults to today, from+to as inclusive range, dates as a specific set, compact for wide ranges, includeSeries for recurring masters, includeBacklog for items, and backlogQuery for finding by name. It adds meaning beyond the schema's bare patterns and booleans.

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 opens with a specific verb and resource: 'Read the calendar — the day's agenda, what's on, how busy you are, your availability, an overview of a day or week, where your time goes.' This clearly distinguishes it from siblings like find_event (searching), get_weather (weather detail), and show_day (display), and it notes the output is a comprehensive bundle for reasoning about the plan.

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?

It explicitly states when to use: 'Call it before scheduling to anchor relative times ('this afternoon')' and provides alternatives: 'call get_weather only for hourly detail' and 'place/manage them with manage_backlog.' It also clarifies default behavior (today) and range/date options, giving clear context and exclusions.

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

All reassign tools Inspect

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.

Get schedule

Input Schema

TDQS

Glama MCP Gateway

TDQS

Resources