Skip to main content
Glama

Get recurring meeting

get_recurring_meeting
Read-onlyIdempotent

Read a recurring meeting series and retrieve its schedule, next occurrences, and each slot's start time and meeting ID for initializing or canceling individual meetings.

Instructions

Read one recurring series in full: the schedule plus its next occurrences.

This is the step before touching any occurrence: the occurrences rows carry the exact start_time strings that init_recurring_meeting_occurrence and cancel_recurring_meeting_occurrence key on, and the meeting_id that get_meeting / delete_meeting take once a slot is instantiated.

Returns the series fields (schedule, duration_hours, location, author, template_meeting_id) plus occurrences in date order: {start_time, state, meeting_id}. state is 'planned' for a slot that exists only in the schedule; once instantiated it is the backing meeting's own state, and only then is meeting_id non-null.

Pitfalls. occurrences is capped at the next few slots — notes says when the cap was hit, and an unbounded series always computes more. The template meeting (its agenda seeds every occurrence) is edited through the regular meeting tools via template_meeting_id; while it is still a draft, occurrences cannot be initialized. A 404 means a wrong id, no 'view meetings' permission, the module is off — or OpenProject before 17.4, which has no recurring-meetings API; the hint names all readings.

Cross-references: list_recurring_meetings for the series id; init_recurring_meeting_occurrence / cancel_recurring_meeting_occurrence for one slot; update_meeting on the template to build the shared agenda or publish a draft template; delete_recurring_meeting to remove the whole series.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
recurring_meeting_idYesNumeric series id from list_recurring_meetings. Never a meeting id — a series and its occurrences are different resources.

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?

Annotations already mark it read-only and non-destructive, but the description adds significant behavioral detail: occurrences are capped with a `notes` field indicating when the cap was hit, template edits go through regular meeting tools, draft templates block initialization, and a 404 can mean four different things including API version compatibility. This goes far 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.

Conciseness5/5

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

The description is long but every sentence has purpose. It is front-loaded with a one-line summary, then structured into use-case, return format, pitfalls, and cross-references. Formatting with code spans and paragraph breaks improves scannability without wasting words.

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 read tool with one parameter, an output schema, and good annotations, the description fully covers return fields, occurrence state semantics, the cap pitfall, template behavior, and error interpretation. It also positions the tool within the broader toolset, making it complete for an agent to select and invoke correctly.

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% — the parameter `recurring_meeting_id` is already described as 'Numeric series id from list_recurring_meetings. Never a meeting id'. The description reinforces this by saying to use `list_recurring_meetings` for the series id, but doesn't add substantially new parameter-specific meaning beyond the schema.

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 opens with 'Read one recurring series in full: the schedule plus its next occurrences,' which clearly states a specific verb (read) and resource (recurring series). It distinguishes from siblings like list_recurring_meetings (listing all series), init/cancel occurrence (modifying a single slot), and delete_recurring_meeting (removing the whole series).

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 frames this as 'the step before touching any occurrence' and explains how the returned `start_time` and `meeting_id` feed into other tools. Cross-references name exact alternatives: `list_recurring_meetings` for the series id, `init_recurring_meeting_occurrence` / `cancel_recurring_meeting_occurrence` for a slot, `update_meeting` on the template, and `delete_recurring_meeting` for the whole series. This is clear when-to-use and when-not-to-use guidance.

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