Skip to main content
Glama
Sign In
OpenProject CE MCP

OpenProject CE MCP

by jtauschl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_recurring_meeting

Create a recurring meeting series by defining frequency, interval, and end rules; the template meeting starts as a draft until occurrences are initialized.

Instructions

Create a recurring meeting series; its template meeting starts as a draft.

Requires OpenProject 17.4+. For a single meeting use create_meeting. Occurrences are virtual until init_recurring_meeting_occurrence creates one; the series is changed with update_recurring_meeting.

Input Schema

NameRequiredDescriptionDefault
titleYesSeries title, at most 255 characters.
confirmNofalse: preview only, nothing changes. true: applies it; get the user's approval of the preview first.
projectYesProject identifier, id, or name; a unique part of a name or identifier also matches.
end_dateNoLast date (YYYY-MM-DD); required for end_after "specific_date".
intervalNoEvery n-th day, week or month, 1 to 100; "working_days" always uses 1.
end_afterNo"never" (default), "specific_date" (requires end_date) or "iterations" (requires iterations).
frequencyYes"daily", "working_days", "weekly", and from 17.5 "monthly_day_of_month" or "monthly_nth_weekday".
iterationsNoNumber of occurrences, 1 to 1000; required for end_after "iterations".
start_timeYesFirst occurrence, ISO 8601 date-time with offset; its time of day is the series'.
monthly_dayNoDay of month, 1 to 31; required for "monthly_day_of_month".
monthly_ordinalNo"1" to "4", or "-1" for the last; required for "monthly_nth_weekday".
monthly_weekdayNoLowercase English weekday, e.g. "monday"; required for "monthly_nth_weekday".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.4

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare non-read-only, non-destructive, non-idempotent, open-world; the description adds real behavioral context beyond them — the template meeting is created as a draft, and occurrences do not exist until initialized. It does not cover the preview/confirm workflow or authentication needs, but the confirm preview semantics are already spelled out in the schema, so the remaining gap is minor.

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?

Three short sentences, front-loaded with the action and the object, then the sibling routing, then the occurrence lifecycle. Nothing is wasted and the line breaks do not impede reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter scheduling tool with no output schema, the description covers version requirements, sibling alternatives, draft state, and occurrence lifecycle. The only real omission is what the call returns (e.g. the series identifier an agent would need for follow-up calls), which the schema cannot supply.

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 description coverage is 100%, so all twelve parameters including the frequency/end_after conditional dependencies are already documented. The description adds no parameter-level meaning beyond the schema (no frequency/interval interaction guidance), so the baseline 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?

States a specific verb and resource ('Create a recurring meeting series') and immediately distinguishes the artifact from a single meeting and from the series' individual occurrences. An agent can tell this apart from create_meeting, update_recurring_meeting, and init_recurring_meeting_occurrence without opening a schema.

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?

Explicitly routes the agent: 'For a single meeting use create_meeting' and 'the series is changed with update_recurring_meeting', plus the prerequisite 'Requires OpenProject 17.4+'. It also flags that occurrences are virtual until init_recurring_meeting_occurrence creates one, which is the key alternative an agent would otherwise get wrong.

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

Deploy Server

Other Tools