Skip to main content
Glama

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, activityTypes and projects (the lookup lists for areaId / activityTypeId / projectId; a project has an areaId; an archived project has archived: true, refuses new links, and comes back with a manage_categories update archived: false), userPreferences, and a days array. Each day has its events, its freeSlots, and its blocking load per area, activity type and project (projectId null is no project; non-blocking overlay load comes separately). A read of more than one day also has a top-level loadByProject, the sum of its days (for example, a week). 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 series as series (the live ones and the ones in the range, with no notes). Pass includeLookups: false on a later call to leave out areas, activityTypes, projects and integrations.

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 (with mirrorStyles when a copy is private or busy). 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 (a calendar's timezone is information only; every span uses the top-level timezone; a calendar's copyStyle applies to copies when mirrorStyles omits that calendar). For a single day, a one-line weather headline is included when the user has a city. For one day, pass includeWeather: true for the full forecast (an outdoor plan only) and includeEnergy: true for the energy curve (energy: peak and dip windows from logged sleep), to put focus work in a peak.

Inbox: backlogCount is the number of Inbox blocks (un-timed intentions). Pass includeBacklog: true for the items (top of tray first, up to 50); backlogPlannedOn, backlogProjectId (an id or "none"), backlogMinPriority (0 to 4) and backlogOffset filter or page them and need includeBacklog: true; with a filter, backlogMatchedCount is the number of matches. Each item has a projectId and a priority (0 none, 1 low, 2 medium, 3 high, 4 urgent). To find an item by name, use find_event. When nextBacklogOffset is not null, pass it as backlogOffset with the same filters for the next page. Place or manage items with manage_inbox.

Input Schema

NameRequiredDescriptionDefault
toYesLast day of the range, inclusive.
fromYesFirst day of the range, inclusive.
minDurationNoReturn only the `freeSlots` of at least this many minutes.
backlogOffsetNoInbox page offset from nextBacklogOffset; keep the same filters. Needs includeBacklog: true.
includeEnergyNoAdd `energy`: the user's forecast energy curve for the day (peak and dip windows, the current level today, calibration state), built from logged sleep. Use it to put focus work in a peak and admin in a dip. With no logged sleep it is a short nudge to log sleep. Needs one day (`from` equal to `to`).
includeSeriesNoAlso return the recurring masters as `series`.
includeBacklogNoInclude the Inbox items (the `backlog` array), not just `backlogCount`. Pass true when the user wants to see, schedule, or manage their Inbox.
includeLookupsNoDefault true. Pass false to leave out `areas`, `activityTypes`, `projects` and `integrations` when you already have them from an earlier read.
includeWeatherNoReplace the one-line `weather` headline with the full forecast for the day (condition, temperature range, rain window, daylight, and a part-of-day breakdown). Use it only for an outdoor or weather-sensitive plan, or when the user asks about the weather. Needs one day (`from` equal to `to`).
weatherLocationNoA city or place name to forecast instead of the user's own city, e.g. "London". The forecast date and times are local to that place; the report names its timezone. Needs includeWeather: true.
backlogPlannedOnNoFilter the Inbox blocks to those planned for this day (a planned day, or a planned window that covers it). Needs includeBacklog: true.
backlogProjectIdNoFilter the Inbox blocks to one project id, or "none" for the blocks with no project. Needs includeBacklog: true; composes with the other filters.
backlogMinPriorityNoFilter the Inbox blocks to a priority of at least this value (0 none, 1 low, 2 medium, 3 high, 4 urgent). Needs includeBacklog: true; composes with the other filters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / backlogMinPriority
      Added value: +{
      +  "description": "Filter the Inbox blocks to a priority of at least this value (0 none, 1 low, 2 medium, 3 high, 4 urgent). Needs includeBacklog: true; composes with the other filters.",
      +  "maximum": 4,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / backlogProjectId
      Added value: +{
      +  "description": "Filter the Inbox blocks to one project id, or \"none\" for the blocks with no project. Needs includeBacklog: true; composes with the other filters.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / properties / includeLookups / description
      Previous value: -"Default true. Pass false to leave out `areas`, `activityTypes` and `integrations` when you already have them from an earlier read."New value: +"Default true. Pass false to leave out `areas`, `activityTypes`, `projects` and `integrations` when you already have them from an earlier read."
  2. Changed4 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / llm_model
      Removed value: -{
      -  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
      -  "type": "string"
      -}
    • addedInput schema / properties / minDuration
      Added value: +{
      +  "description": "Return only the `freeSlots` of at least this many minutes.",
      +  "maximum": 1440,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "from",
      -  "to",
      -  "llm_model"
      -]New value: +[
      +  "from",
      +  "to"
      +]
  3. Changed5 schema fields changed
    • changedInput schema / properties / backlogPlannedOn / description
      Previous 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."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."
    • removedInput schema / properties / backlogQuery
      Removed value: -{
      -  "description": "Filter the Inbox blocks by name (fuzzy, case/accent-insensitive), e.g. \"dentist\". Needs includeBacklog: true.",
      -  "minLength": 1,
      -  "type": "string"
      -}
    • addedInput schema / properties / includeEnergy
      Added value: +{
      +  "description": "Add `energy`: the user's forecast energy curve for the day (peak and dip windows, the current level today, calibration state), built from logged sleep. Use it to put focus work in a peak and admin in a dip. With no logged sleep it is a short nudge to log sleep. Needs one day (`from` equal to `to`).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / includeWeather
      Added value: +{
      +  "description": "Replace the one-line `weather` headline with the full forecast for the day (condition, temperature range, rain window, daylight, and a part-of-day breakdown). Use it only for an outdoor or weather-sensitive plan, or when the user asks about the weather. Needs one day (`from` equal to `to`).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / weatherLocation
      Added value: +{
      +  "description": "A city or place name to forecast instead of the user's own city, e.g. \"London\". The forecast date and times are local to that place; the report names its timezone. Needs includeWeather: true.",
      +  "minLength": 1,
      +  "type": "string"
      +}
  4. Changed2 schema fields changed
    • removedInput schema / properties / conversation_id
      Removed value: -{
      -  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
      -  "type": "string"
      -}
    • addedInput schema / properties / includeLookups
      Added value: +{
      +  "description": "Default true. Pass false to leave out `areas`, `activityTypes` and `integrations` when you already have them from an earlier read.",
      +  "type": "boolean"
      +}
  5. Changed4 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / llm_model
      Added value: +{
      +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "from",
      -  "to"
      -]New value: +[
      +  "from",
      +  "to",
      +  "llm_model"
      +]
  6. Changed11 schema fields changed
    • 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"
      +]
  7. Changed2 schema fields changed
    • 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"
      +}
  8. Changed3 schema fields changed
    • 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."
  9. Changed1 schema field changed
    • 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"
      +}
  10. Changed2 schema fields changed
    • 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"
      +}
  11. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint, so the description carries the real burden and delivers: readOnly events on non-owned calendars, non_blocking overlays, reference events whose hours stay free, DST `warning` semantics, project archival behavior, and backlog pagination via nextBacklogOffset. This is rich context well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense wall of heavily parenthesized clauses that pack multiple rules per sentence, making it hard to scan for a single parameter's behavior. Much of the length is justified by the missing output schema, but it is not tightly edited.

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?

For a 13-parameter read tool with no output schema, the description documents the return shape (days, events, freeSlots, load rollups, series, weather, energy, backlog), edge cases, and cross-parameter requirements thoroughly. Nothing an agent needs to call it correctly is missing.

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 100% so the baseline is 3, but the description adds real semantics: from/to are inclusive and equal for one day, includeLookups:false is for a later call when lookups are already held, backlog filters all require includeBacklog:true, and nextBacklogOffset is replayed as backlogOffset with the same filters.

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?

Opens with a specific, vivid statement of what the tool reads ('the agenda, what is on, how busy the user is, free time, or where the time goes') and then enumerates the actual payload (now, timezone, areas, days, events, freeSlots, load). An agent can tell it apart from write/manage siblings immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use ('Call it before you schedule, to anchor relative times') and routes two sibling cases away (find_event for finding an item by name, manage_inbox for placing items). It stops short of full differentiation from show_day and review_day, which also read day data.

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.