---
name: context-aware-scheduling
description: Design, validate, explain, and preview timezone-safe schedules with rrule.net. Use when a task involves recurring time, cron or RRule migration, natural-language schedules, exclusions, event-relative timing, business calendars, multiple locations, or execution targets.
metadata:
  author: rrule.net
  version: "1.0"
---

# Context-aware scheduling with rrule.net

Use the public rrule.net MCP server at `https://mcp.rrule.net` when a user needs a schedule to be interpreted, validated, explained, or simulated.

When operating on an rrule.net page in a browser that supports WebMCP, the same
`validate_schedule`, `simulate_schedule`, and `describe_schedule` tools may be
available directly from the page. Their inputs and read-only behavior mirror
the public MCP server, so use the available transport without changing the
workflow below.

The exploration MCP tools are read-only. They do not create, persist, pause, resume, or delete schedules. Never claim that a schedule is active after using them. Use the separate `hosted-schedule-operations` skill only when the user explicitly wants persistent execution and authenticated tools are available.

## Choose the scheduling intent

Before calling a tool, identify the details that affect meaning:

- whether the user means elapsed time or a wall-clock time;
- the IANA timezone for every wall-clock time;
- inclusions, exclusions, bounds, and business-day constraints;
- whether timing is relative to an explicit event or window;
- whether several audiences, regions, systems, or locations need distinct execution targets.

Prefer natural language when it states the intent clearly. Treat cron and RRule as compatibility inputs, not as the canonical model. Do not flatten a composed or target-aware schedule into one RRule when that would lose meaning.

## Validate before simulation

1. Call `validate_schedule` with exactly one of `input`, `recurrence`, or `event_schedule`, plus an IANA `timezone`.
2. Check `valid`, the explanation, ambiguities, timezone, normalized recurrence, and any returned targets.
3. If the result exposes an ambiguity or silently requires a timezone the user did not provide, ask the user before continuing.
4. Preserve returned target ids, labels, timezones, recurrence sources, and metadata as one logical schedule.

Example arguments:

```json
{
  "input": "Every day at 9am local time in Paris, London, Moscow, and Perth",
  "timezone": "UTC"
}
```

## Preview occurrences

Call `simulate_schedule` before recommending that a schedule be used in production. Request enough occurrences to cross relevant boundaries such as a weekend, month end, daylight-saving transition, exclusion, or event window.

Report both:

- the local wall-clock interpretation and timezone;
- the corresponding UTC instants when they help the user verify execution.

For target-aware schedules, keep results grouped by target. A single UTC list without target context is incomplete.

## Explain safely

Use `describe_schedule` when the user already has a schedule representation and needs a concise human-readable explanation without a full simulation.

Always call out:

- DST-sensitive wall-clock behavior;
- finite bounds such as count or end date;
- exclusions and intersections;
- event-relative timing;
- target-specific timezones or routing context.

Never invent support for a calendar rule that validation rejected. Return the validation error and suggest an explicit, testable alternative.

## Useful references

- MCP documentation: https://rrule.net/docs/mcp
- API documentation: https://rrule.net/docs/api
- Event scheduling guide: https://rrule.net/guides/contextual-scheduling
- Schedule targets guide: https://rrule.net/guides/schedule-targets