Skip to main content
Glama

Create recurring meeting

create_recurring_meeting

Create a recurring meeting series (schedule + template) in OpenProject, with local validation of frequency and end conditions. Use for weekly syncs or monthly meetings.

Instructions

Create a recurring meeting series: a schedule plus a template the occurrences copy.

Use it for "set up a weekly sync Mondays at 9" style requests. The frequency and end_after combinations are validated locally BEFORE anything is sent — OpenProject's own "infer the monthly fields" defaults never apply to API creates, so a bad combination is rejected here with the allowed matrix spelled out.

Returns the created series in the same shape as get_recurring_meeting, including the computed next occurrences (their start_time strings are what the occurrence tools take) and template_meeting_id.

Pitfalls — two upstream quirks are handled but must be understood. First, the template meeting is created as a DRAFT: notes says so, and occurrences cannot be initialized until update_meeting(meeting_id=<template_meeting_id>, state='open') publishes it. Second, OpenProject overwrites time_zone on create with the API account's own zone; this tool detects that and corrects it with a follow-up PATCH — if that correction is refused (it needs 'edit meetings'), the series is still created and notes names the zone it actually runs in. start_time must be now or in the future, or the create is rejected with a validation error.

Cross-references: get_recurring_meeting to read it back; update_meeting(meeting_id=<template_meeting_id>, ...) to build the shared agenda and publish the template; init_recurring_meeting_occurrence to materialize a slot; list_projects for the project id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesSeries title, e.g. 'Weekly team sync'.
notifyNoTrue emails participants about schedule changes and cancellations. Defaults to false — an API-created series stays quiet.
end_dateNoLast possible date as 'YYYY-MM-DD'; required for, and only valid with, end_after='specific_date'.
intervalNoEvery N days/weeks/months (default 1 = every occurrence of the rule). Not applicable to 'working_days'.
locationNoRoom name or meeting URL every occurrence inherits. Omit for none.
end_afterNoHow the series ends: 'never' (the default), 'specific_date' (needs end_date) or 'iterations' (needs iterations).never
frequencyNoRepetition rule: 'daily', 'working_days' (every working day), 'weekly' (the default), 'monthly_day_of_month' (needs monthly_day) or 'monthly_nth_weekday' (needs monthly_ordinal + monthly_weekday).weekly
time_zoneYesIANA time zone the schedule computes in, e.g. 'Europe/Berlin' or 'Etc/UTC' — required, because it decides what 'every Monday 09:00' means across DST changes. Validated locally: OpenProject would store a typo silently and fall back to the account's zone.
iterationsNoTotal number of occurrences (1-1000); required for, and only valid with, end_after='iterations'.
project_idYesNumeric id or identifier of the project the series belongs to. It must have the Meetings module enabled and this account needs the 'create meetings' permission in it.
start_timeYesFirst occurrence as ISO 8601 WITH a timezone: '2026-09-01T09:00:00Z' or '2026-09-01T11:00:00+02:00'. Must be now or in the future; a time without an offset is rejected locally.
monthly_dayNoDay of the month (1-31); required for, and only valid with, frequency='monthly_day_of_month'.
monthly_ordinalNoWhich weekday of the month: 1-4, or -1 for the last one; required for, and only valid with, frequency='monthly_nth_weekday'.
monthly_weekdayNoWeekday name ('monday'…'sunday'); required for, and only valid with, frequency='monthly_nth_weekday'.
duration_minutesYesLength of each occurrence in minutes (90 = one and a half hours). The result reports it back as duration_hours.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoSeries id — what get_recurring_meeting and the occurrence tools take. Not a meeting id.
notesNoDegradation markers: an unreadable schedule, the occurrence cap, a time zone that could not be applied, a draft template.
titleNoSeries title.
authorNoUser who created the series.
projectNoProject the series belongs to.
end_dateNoLast possible date (ISO); only when end_after='specific_date'.
intervalNoEvery N days/weeks/months; always 1 for 'working_days'.
locationNoRoom name or meeting URL each occurrence inherits.
end_afterNo'never', 'specific_date' or 'iterations'.
frequencyNoRepetition rule: 'daily', 'working_days', 'weekly', 'monthly_day_of_month' or 'monthly_nth_weekday'.
time_zoneNoZone the schedule computes in, as OpenProject stores it (an IANA identifier or a Rails zone name).
iterationsNoTotal occurrences; only when end_after='iterations'.
start_timeNoFirst-occurrence start as ISO 8601 UTC.
monthly_dayNoDay of month (1-31); only for 'monthly_day_of_month'.
occurrencesNoThe next upcoming slots in order (capped; see 'notes'). meeting_id is null until a slot is instantiated, and state 'planned' marks exactly those.
duration_hoursNoLength of each occurrence in hours (1.5 = 90 minutes).
monthly_ordinalNoWhich weekday occurrence (1-4, -1 = last); only for 'monthly_nth_weekday'.
monthly_weekdayNoWeekday name; only for 'monthly_nth_weekday'.
template_meeting_idNoId of the template meeting the occurrences are copied from. Its agenda is edited with the regular meeting tools, and a freshly created template is a DRAFT — publish it with update_meeting(meeting_id=<this>, state='open') before initialising occurrences.
Behavior5/5

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

The description discloses extensive behavioral traits beyond annotations: local validation of frequency/end_after combinations, template created as DRAFT, time_zone overwrite and follow-up PATCH, permission requirements, and start_time validation. Annotations only provide basic hints (readOnlyHint false, idempotentHint false), so the description carries the full burden and excels.

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 long but appropriately structured: purpose first, then usage, return shape, pitfalls, and cross-references. Every sentence provides necessary context for a tool with 15 parameters and multiple upstream quirks. No fluff or redundancy; it earns its length.

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?

Despite an output schema existing, the description still explains the return shape (same as get_recurring_meeting, with occurrences and template_meeting_id). It covers permissions, project module requirements, validation behavior, the draft-template workflow, timezone correction, and related tools. This is comprehensive for the complexity of the tool.

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 baseline is 3. The description adds cross-parameter semantics by explaining that frequency and end_after combinations are validated locally, and that OpenProject's infer defaults never apply. It also clarifies that start_time must be now or future and time_zone is validated, adding value beyond the already-rich schema descriptions.

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 clearly states the tool's purpose: 'Create a recurring meeting series: a schedule plus a template the occurrences copy.' This goes beyond a generic 'create' verb, specifying the resource (recurring meeting series) and distinguishing it from single-meeting tools like create_meeting in the sibling list.

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?

The description explicitly says 'Use it for "set up a weekly sync Mondays at 9" style requests,' and provides cross-references to related tools for different steps (e.g., get_recurring_meeting, update_meeting, init_recurring_meeting_occurrence, list_projects). This gives clear when-to-use and alternative context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server