reassign

Get schedule

get_schedule

Read-only

Read the calendar: the agenda, what is on, how busy the user is, free time, or where the time goes. One call returns the current local time (now, "YYYY-MM-DDTHH:MM"), the user's timezone, the user's areas and activityTypes (the lookup lists for areaId / activityTypeId), userPreferences, and a days array. Each day has its events, its freeSlots, and its blocking load per area and activity type (non-blocking overlay load comes separately). Call it before you schedule, to anchor relative times ('this afternoon'). Pass from and to (ISO YYYY-MM-DD, inclusive; equal for one day). Pass includeSeries: true to also get the recurring masters as series.

Time spans: every event and free slot is start + end, two local datetimes "YYYY-MM-DDTHH:MM" in the top-level timezone (e.g. start "2026-09-23T22:00", end "2026-09-24T01:00"). The end is always after the start; a slot to midnight ends at the next day's T00:00. An event from an earlier day that runs into this day is listed first, with its real start, on every day that it touches; only its time inside the day counts for load and free slots. A warning marks a start time that a DST change skips.

Each event carries its source ("reassign", else a provider like "google"), its home calendarId (absent = the default calendar, null = dial only) and any mirrorCalendarIds. An event with readOnly: true is on a calendar the user does not own: do not edit or delete it (tell them to change it there). kind "non_blocking" is an overlay that may overlap others (fasting, an away marker); "reference" is see-only: its hours stay free, so do not move, delete, or schedule work into it unless asked. A confirmed past day carries a review adherence rollup and per-event reflect actuals; use them for how a day or week actually went. When a calendar is connected, integrations describes it. For a single day, a one-line weather headline is included when the user has a city; call get_weather only for hourly detail.

Inbox: backlogCount is the number of Inbox blocks (un-timed intentions). Pass includeBacklog: true for the items (top of tray first, up to 50); backlogQuery, backlogPlannedOn and backlogOffset filter or page them and need includeBacklog: true. When nextBacklogOffset is not null, pass it as backlogOffset with the same filters for the next page. Place or manage items with manage_backlog.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Last day of the range, inclusive.
`from`	Yes	First day of the range, inclusive.
`backlogQuery`	No	Filter the Inbox blocks by name (fuzzy, case/accent-insensitive), e.g. "dentist". Needs includeBacklog: true.
`backlogOffset`	No	Inbox page offset from nextBacklogOffset; keep the same filters. Needs includeBacklog: true.
`includeSeries`	No	Also return the recurring masters as `series`.
`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 planned day, or a planned window that covers it). Needs includeBacklog: true; composes with backlogQuery.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 23, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / backlogOffset / description

Previous value: -"Inbox page offset from nextBacklogOffset; keep the same filters. Implies includeBacklog."New value: +"Inbox page offset from nextBacklogOffset; keep the same filters. Needs includeBacklog: true."

changedInput schema / properties / backlogPlannedOn / description

Previous value: -"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."New value: +"Filter the Inbox blocks to those planned for this day (a planned day, or a planned window that covers it). Needs includeBacklog: true; composes with backlogQuery."

changedInput schema / properties / backlogQuery / description

Previous value: -"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."New value: +"Filter the Inbox blocks by name (fuzzy, case/accent-insensitive), e.g. \"dentist\". Needs includeBacklog: true."

removedInput schema / properties / compact

Removed value: -{
-  "type": "boolean"
-}

removedInput schema / properties / date

Removed value: -{
-  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
-  "type": "string"
-}

removedInput schema / properties / dates

Removed value: -{
-  "items": {
-    "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
-    "type": "string"
-  },
-  "maxItems": 366,
-  "type": "array"
-}

addedInput schema / properties / from / description

Added value: +"First day of the range, inclusive."

addedInput schema / properties / includeSeries / description

Added value: +"Also return the recurring masters as `series`."

addedInput schema / properties / to / description

Added value: +"Last day of the range, inclusive."

addedInput schema / required
```
Added value: +[
+  "from",
+  "to"
+]
```

Changed2 schema fields changedSep 20, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / backlogOffset

Added value: +{
+  "description": "Inbox page offset from nextBacklogOffset; keep the same filters. Implies includeBacklog.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

Changed3 schema fields changedAug 17, 2026

changedInput schema / properties / backlogPlannedOn / description

Previous value: -"Filter the parked 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."New value: +"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."

changedInput schema / properties / backlogQuery / description

Previous value: -"Filter the parked blocks by name (fuzzy, case/accent-insensitive) — e.g. \"dentist\". Implies includeBacklog; use it to FIND a specific parked block by name instead of paging the whole inbox."New value: +"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."

changedInput schema / properties / includeBacklog / description

Previous value: -"Include the parked-block items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their inbox."New value: +"Include the Inbox items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their Inbox."

Changed1 schema field changedJul 16, 2026

addedInput schema / properties / backlogPlannedOn

Added value: +{
+  "description": "Filter the parked 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.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

Changed2 schema fields changedJul 6, 2026

addedInput schema / properties / backlogQuery

Added value: +{
+  "description": "Filter the parked blocks by name (fuzzy, case/accent-insensitive) — e.g. \"dentist\". Implies includeBacklog; use it to FIND a specific parked block by name instead of paging the whole inbox.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / includeBacklog

Added value: +{
+  "description": "Include the parked-block items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their inbox.",
+  "type": "boolean"
+}

First observedJun 14, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description goes far beyond the readOnlyHint/openWorldHint annotations by documenting inclusive ranges, cross-day event handling, DST warnings, readOnly calendar semantics, non_blocking/reference event kinds, review/reflect actuals, and backlog pagination. It also tells the agent what not to do with certain returned events, which is behavior annotations alone cannot express.

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 long, but the tool has no output schema and returns a rich document, so most of the length is justified. It is front-loaded with purpose and required parameters before the detailed return semantics, and the paragraphs are logically grouped. Still, some event-level detail could be trimmed or moved to an output schema if one existed.

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 the absence of an output schema, the description carries the full burden of explaining the return shape, and it does so comprehensively: timezones, events, free slots, event kinds, calendar semantics, weather, and inbox pagination. An agent has enough context to invoke the tool correctly and interpret its response.

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?

The input schema describes all 7 parameters, but the description adds meaning: from/to are ISO and inclusive, equal for one day; includeSeries returns recurring masters; includeBacklog returns items top-of-tray-first up to 50; and backlogOffset pagination must preserve the same filters. This is genuinely useful operational detail beyond the schema.

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–resource pair ('Read the calendar') and immediately clarifies scope: agenda, busyness, free time, and where time goes. It also distinguishes itself from sibling tools by saying to call it before scheduling, to use get_weather only for hourly detail, and to use manage_backlog for Inbox item management.

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 directs 'Call it before you schedule, to anchor relative times,' and explains when to pass includeSeries and includeBacklog. It also gives explicit when-not-to-use guidance for get_weather and routes backlog management to manage_backlog, giving an agent clear selection criteria.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Get schedule

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources