Skip to main content
Glama

Create a schedule

create_schedule

Create a recurring (or custom-date) schedule and materialize its upcoming occurrences. Best practice: call preview_schedule_occurrences with the same recurrence settings first and confirm the dates with the user. This tool returns the created schedule AND an inline preview of its next occurrences so you can show what was set up. You can optionally seed the roster with contact_ids at creation. Requires the schedules:write scope. If calendar invites are on for the account, assigned volunteers may get a new, updated or cancelled calendar invite by email (in test mode it goes to the owner instead).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "description": "<description>",
      "job_name": "<job_name>",
      "schedule_type": "<schedule_type>"
    },
    "name": "create_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
timeNoWall-clock time of day "HH:mm" (24-hour) in the account timezone, or null for no specific time.
notesNoFree-text internal notes, or null.
end_dateNo"yyyy-MM-dd" (account timezone) after which occurrences stop, or null for no end date.
group_idNoId of an existing volunteer group to attach, or null. Unknown ids are ignored.
job_nameYesThe role/task volunteers are reminded about. Matched case-insensitively against the account's existing jobs and created if new.
start_dateNo"yyyy-MM-dd" (account timezone) before which no occurrences materialize, or null for no lower bound. For 'biweekly' this also picks which week the 14-day rotation lands on; when omitted, the server uses the first selected weekday after today. Updating an existing biweekly schedule with null keeps its stored date.
contact_idsNoOptional initial roster (volunteer contact ids) to assign at creation. Ids not owned by this account are silently dropped. To change a roster later, use assign_contacts_to_schedule.
descriptionYesShort label shown on the schedule list and in reminders, e.g. "Sunday greeters".
nth_weekdayNoThe weekday that recurs, for schedule_type 'monthly_nth'/'bimonthly_nth'. Defaults to sunday for those types.
start_monthNoAnchor month (1=January … 12=December) the every-other-month cadence steps from, for the 'bimonthly_*' types. Defaults to the account's current month.
custom_datesNoExplicit list of "yyyy-MM-dd" dates. Required (non-empty) when schedule_type is 'custom'; ignored otherwise.
day_of_monthNoFixed day of the month for the 'fixed' types. Defaults to 1. Clamped to the last day of shorter months (e.g. 31 in February becomes the 28th/29th).
days_of_weekNoWeekday names this recurs on, e.g. ["tuesday","thursday"]. Required (non-empty) when schedule_type is 'weekly' or 'biweekly'; ignored otherwise.
schedule_typeYesRecurrence shape. 'weekly' recurs on one or more days of the week; 'biweekly' is the same weekday mask every 14 days (start_date picks which week; not BiMonthly, which is every other month); 'monthly_fixed'/'bimonthly_fixed' recur on a fixed day of the month; 'monthly_nth'/'bimonthly_nth' recur on the Nth weekday of the month; the 'bimonthly_*' variants also alternate months starting from start_month; 'custom' uses an explicit list of dates.
week_of_monthNoWhich occurrence of the weekday in the month (1st–5th), for the Nth-weekday types. Defaults to 1.

Output Schema

NameRequiredDescriptionDefault
scheduleYes
upcoming_occurrencesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / days_of_week / description
      Previous value: -"Weekday names this recurs on, e.g. [\"tuesday\",\"thursday\"]. Required (non-empty) when schedule_type is 'weekly'; ignored otherwise."New value: +"Weekday names this recurs on, e.g. [\"tuesday\",\"thursday\"]. Required (non-empty) when schedule_type is 'weekly' or 'biweekly'; ignored otherwise."
    • changedInput schema / properties / schedule_type / description
      Previous value: -"Recurrence shape. 'weekly' recurs on one or more days of the week; 'monthly_fixed'/'bimonthly_fixed' recur on a fixed day of the month; 'monthly_nth'/'bimonthly_nth' recur on the Nth weekday of the month; the 'bimonthly_*' variants also alternate months starting from start_month; 'custom' uses an explicit list of dates."New value: +"Recurrence shape. 'weekly' recurs on one or more days of the week; 'biweekly' is the same weekday mask every 14 days (start_date picks which week; not BiMonthly, which is every other month); 'monthly_fixed'/'bimonthly_fixed' recur on a fixed day of the month; 'monthly_nth'/'bimonthly_nth' recur on the Nth weekday of the month; the 'bimonthly_*' variants also alternate months starting from start_month; 'custom' uses an explicit list of dates."
    • changedInput schema / properties / schedule_type / enum
      Previous value: -[
      -  "weekly",
      -  "monthly_fixed",
      -  "monthly_nth",
      -  "bimonthly_fixed",
      -  "bimonthly_nth",
      -  "custom"
      -]New value: +[
      +  "weekly",
      +  "biweekly",
      +  "monthly_fixed",
      +  "monthly_nth",
      +  "bimonthly_fixed",
      +  "bimonthly_nth",
      +  "custom"
      +]
    • changedInput schema / properties / start_date / description
      Previous value: -"\"yyyy-MM-dd\" (account timezone) before which no occurrences materialize, or null for no lower bound."New value: +"\"yyyy-MM-dd\" (account timezone) before which no occurrences materialize, or null for no lower bound. For 'biweekly' this also picks which week the 14-day rotation lands on; when omitted, the server uses the first selected weekday after today. Updating an existing biweekly schedule with null keeps its stored date."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=false but openWorldHint=true), the description discloses that occurrences are materialized, that the `schedules:write` scope is required, and that assigned volunteers may receive new/updated/cancelled calendar invites by email, with test mode redirecting to the owner. Those outbound side effects are not derivable from the annotation flags.

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?

The capability statement is front-loaded, followed by best practice, return behavior, a parameter note, and prerequisites/side effects in descending order of importance. Every sentence carries either routing or behavioral information; nothing is redundant.

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 15-parameter creation tool with an output schema and full schema coverage, the description covers what an agent must know: prerequisites, the preview-first workflow, roster seeding, and the external email consequence of creating schedule entries. No gap remains that would cause a misinvocation.

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

Parameters3/5

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

Schema coverage is 100% across 15 parameters, so the schema already carries the heavy lifting on recurrence semantics and defaults. The description adds only one parameter-level detail — that contact_ids optionally seeds the roster at creation — plus the return-shape note; baseline 3 is appropriate.

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 opening sentence names the specific verb and resource ('Create a recurring (or custom-date) schedule and materialize its upcoming occurrences'), and the parenthetical scope distinguishes it from both preview-only and update flows. Combined with the sibling list, an agent can separate this from update_schedule or preview_schedule_occurrences without reading schemas.

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 routes the agent to preview_schedule_occurrences first with matching recurrence settings and to confirm dates with the user, and it names assign_contacts_to_schedule as the alternative for later roster changes. Both the when-to-use and the follow-up path are stated rather than implied.

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.

Resources