Skip to main content
Glama

Init recurring meeting occurrence

init_recurring_meeting_occurrence
Idempotent

Materialize a scheduled occurrence of a recurring meeting into an editable meeting, copying agenda and attachments so you can prepare minutes or files; also restores cancelled slots.

Instructions

Materialize one occurrence of a series as a real meeting, copied from the template.

Use it when a specific slot needs its own agenda, minutes or attachments before the day: the occurrence becomes a normal meeting (template agenda and attachments copied) that every meeting tool can work on. Called on a cancelled occurrence it RESTORES it to 'open'; called where an open meeting already exists it idempotently returns that meeting.

Returns the instantiated meeting in the same shape as get_meeting — its id is the meeting id for follow-up calls, distinct from the series id.

Pitfalls — the instant is trusted, not validated. OpenProject matches start_time by timestamp equality and does NOT check it against the schedule, so a wrong instant creates a real off-schedule meeting: always copy the string from get_recurring_meeting's occurrences (offsets are normalized to UTC 'Z' form on the wire). An HTTP 500 here almost always means the series' template is still a DRAFT — OpenProject fails uncleanly on that instead of answering 422; publish the template with update_meeting(meeting_id=<template_meeting_id>, state='open') and retry. This needs the 'create meetings' permission (403 otherwise; OpenProject 17.4 itself briefly wanted 'edit meetings').

Cross-references: get_recurring_meeting for the exact start_time strings and the template id; update_meeting / add_meeting_agenda_item on the result; cancel_recurring_meeting_occurrence for the opposite move.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
start_timeYesThe occurrence's scheduled instant, copied VERBATIM from a get_recurring_meeting occurrences row ('2026-08-12T10:00:00Z'). Matching is exact-instant and OpenProject does not check the value against the schedule — a retyped or rounded time silently creates an off-schedule meeting.
recurring_meeting_idYesNumeric series id from list_recurring_meetings. Never a meeting id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoMeeting id — what get_meeting and add_meeting_agenda_item take.
notesNoDegradation notes: agenda items that could not be read, work packages this account may not see.
stateNoLifecycle state: 'draft' (not yet opened to participants), 'open', 'in_progress', 'closed' or 'cancelled'. Cancelled meetings are excluded from listings.
titleNoMeeting title.
authorNoUser who created the meeting.
projectNoProject the meeting belongs to.
end_timeNoISO 8601 UTC end timestamp, derived from start plus duration.
locationNoRoom name or meeting URL as typed by the organizer.
created_atNoISO 8601 UTC timestamp.
start_timeNoISO 8601 UTC start timestamp; null for an undated meeting.
updated_atNoISO 8601 UTC timestamp.
agenda_itemsNoThe agenda in order; always a list. Empty means either no agenda or an unreadable one — check 'notes' before concluding the meeting had none.
lock_versionNoOptimistic-lock version. Echo it as update_meeting's lock_version so a concurrent edit fails loudly (409) instead of being overwritten.
participantsNoInvited users; always a list. Attendance is not exposed by API v3.
duration_hoursNoScheduled length in hours (1.5 = 90 minutes); the wire sends an ISO duration, which is converted here.
Behavior5/5

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

Beyond the annotations (idempotentHint, openWorldHint), the description discloses critical behaviors: idempotent return of an existing open meeting, restoration of cancelled occurrences, permission requirements, HTTP 500 for draft templates, and the non-validation of the instant leading to off-schedule meetings. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is lengthy but every section earns its place: purpose, usage, return shape, pitfalls, permissions, and cross-references. It is well-structured with clear paragraphs and bullet-like pitfall sections, though slightly verbose; could be tightened without losing critical content.

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?

Given the tool's complexity and the existence of an output schema, the description provides comprehensive context: it explains the returned meeting shape references get_meeting, covers error modes (wrong instant, draft template), permission issues, and cross-references sibling tools. The agent has everything needed to invoke correctly and avoid known pitfalls.

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?

The schema already has 100% coverage with detailed descriptions for both parameters, including the verbatim copy warning for start_time and the distinction between series id and meeting id. The main description repeats these points but adds no new parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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 a specific verb+resource+outcome: 'Materialize one occurrence of a series as a real meeting, copied from the template.' It clearly differentiates this tool from its siblings (e.g., cancel_recurring_meeting_occurrence) by explaining the occurrence becomes a normal meeting that other meeting tools can operate on.

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 states when to use it ('when a specific slot needs its own agenda, minutes or attachments before the day'), describes behavior on cancelled vs. existing occurrences, and points to alternatives like get_recurring_meeting for exact start_time strings and update_meeting for follow-up changes. It also warns against misuse with specific pitfall examples.

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