Skip to main content
Glama
deciduus
by deciduus

Set scheduling preferences

set_preferences
Idempotent

Update and save scheduling preferences—timezone, working hours, buffer, focus blocks, lunch—without restating unchanged settings. Validation rejects invalid changes, leaving saved preferences intact.

Instructions

Update the user's scheduling preferences and save them. Returns the merged result.

Only the arguments you pass change; everything else keeps its current value, so a single correction ("I actually start at 8") does not have to restate the whole schedule. The merged result is validated before it is written, so a rejected change leaves the saved preferences untouched.

Args: timezone: IANA timezone the working hours are expressed in, e.g. 'Europe/Berlin'. Must be a real zone name. working_hours: Whole-schedule replacement, keyed by weekday ('mon'..'sun'), each value a list of ['HH:MM', 'HH:MM'] pairs. Days you omit become non-working, so pass every working day at once, e.g. {"mon": [["09:00", "12:00"], ["13:00", "18:00"]], "fri": [["09:00", "15:00"]]}. buffer_minutes: Minimum gap to leave before and after each meeting when proposing times. 0 disables it. min_focus_block_minutes: Shortest free stretch that still counts as usable focus time. lunch: Daily lunch break as ['HH:MM', 'HH:MM'], carved out of the working hours. focus_calendar_id: Calendar that focus blocks are booked on; 'primary' for the user's own. clear_lunch: Set true to remove an existing lunch break (pass this instead of lunch when the user says they no longer want one).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lunchNo
timezoneNo
clear_lunchNo
working_hoursNo
buffer_minutesNo
focus_calendar_idNo
min_focus_block_minutesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
lunchNoDaily lunch break as ['HH:MM', 'HH:MM'], carved out of the working hours. Omit for no lunch break.
timezoneNoIANA timezone the working hours are expressed in, e.g. 'Europe/Berlin'. Omit to use the calendar's own timezone.
working_hoursNoPer-weekday working spans, keyed 'mon'..'sun', each a list of ['HH:MM', 'HH:MM'] pairs. An empty list means the day is off.
buffer_minutesNoMinimum gap to leave before and after each meeting when scheduling.
focus_calendar_idNoCalendar that focus blocks are booked on.primary
min_focus_block_minutesNoShortest free stretch that still counts as usable focus time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses critical behavior: only passed arguments change, the merged result is validated before writing, rejected changes leave saved preferences untouched, and the tool returns the merged result. This gives an agent an accurate model of side effects and failure behavior.

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 description is substantial but every sentence earns its place. It front-loads merged-result and validation behavior before detailing each parameter, and the examples are directly relevant to avoiding common mistakes.

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 7-parameter tool with no required fields and nuanced update semantics, the description is complete. It covers all parameters, partial-update behavior, validation atomicity, and format expectations. Since an output schema exists, the stated return value is a bonus rather than a requirement.

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 description coverage is 0%, so the description must fully document parameters. It does: all seven parameters are explained with meaning, formats, examples, and important caveats such as working_hours being a whole-schedule replacement and clear_lunch being the way to remove a lunch break.

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 states a specific verb and resource: 'Update the user's scheduling preferences and save them.' This clearly distinguishes the tool from event-manipulation siblings and from get_preferences, which reads rather than writes.

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?

The description makes the tool's usage context clear: it is for updating saved scheduling preferences, with partial-update semantics that make single corrections easy. It does not explicitly name alternatives or exclusion criteria, but the resource and sibling set make the right invocation context unambiguous.

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