Skip to main content
Glama

Create meeting

create_meeting

Create a meeting in a project with specified start time, duration, and optional participants. Receive validation errors for permission or scheduling problems.

Instructions

Schedule a meeting in a project and optionally invite participants.

Use it for "book a review on Thursday" style requests. The call goes through POST /meetings/form first, so a missing permission, an impossible time or a participant who cannot see the project comes back as violations naming the attribute instead of an opaque rejection.

Returns the created meeting in the same shape as get_meeting (its agenda_items are empty — add them with add_meeting_agenda_item).

Pitfalls. Check state in the result: current OpenProject versions create meetings as 'draft', which means participants do not see it until it is opened — update_meeting(meeting_id=..., state='open') publishes it, exactly as the UI does. Invitation emails are not sent by an API create. start_time needs a timezone — the server stores an instant, not a wall-clock time. Recurring meetings cannot be created through this tool — use create_recurring_meeting.

Cross-references: add_meeting_agenda_item(meeting_id=...) to build the agenda; get_meeting to read it back; list_projects for the project id; search_principals (or list_project_memberships) for participant ids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesMeeting title, e.g. 'Sprint 12 planning'.
project_idYesNumeric id or identifier of the project the meeting belongs to. It must have the Meetings module enabled and this account needs the 'create meetings' permission in it.
start_timeYesStart as ISO 8601 WITH a timezone: '2026-08-03T14:00:00Z' (UTC) or '2026-08-03T16:00:00+02:00'. A time without an offset is rejected locally rather than booked in the wrong hour.
participantsNoUser ids to invite, from search_principals or a project's memberships. Every one of them needs 'view meetings' in the project or the create is rejected. Omit to let OpenProject invite only the author.
duration_minutesYesScheduled length in minutes (90 = one and a half hours). Sent as the API's ISO duration; the result reports it back as duration_hours.

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?

The description adds significant behavioral context beyond annotations: it reveals the POST /meetings/form endpoint behavior (violations naming the attribute), draft state pitfall, lack of invitation emails, timezone storage semantics, and non-support for recurring meetings. This complements the annotations (readOnlyHint=false, idempotentHint=false) without contradiction.

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 well-structured with a purpose statement, usage context, pitfalls, and cross-references. While moderately long, every sentence conveys essential operational information—no filler or repetition of schema fields. Front-loaded with the action and key use case.

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?

With a rich output schema and sibling context, the description fully covers the tool's behavior: return shape (same as get_meeting with empty agenda_items), how to add agenda items, and all necessary cross-references (list_projects, search_principals, update_meeting for state). It equips the agent to use the tool correctly end-to-end.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% coverage with thorough descriptions for each parameter. The description adds extra value by explaining the timezone requirement for start_time, the view-meetings permission for participants, and the ISO duration conversion for duration_minutes, enriching the schema's meaning.

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: 'Schedule a meeting in a project and optionally invite participants.' It clearly distinguishes from sibling tools by explicitly stating recurring meetings are not supported (use create_recurring_meeting) and referencing add_meeting_agenda_item for agenda building.

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?

Provides explicit usage context ('Use it for "book a review on Thursday" style requests'), prerequisites (project must have Meetings module, permissions), and exclusions (recurring meetings). Cross-references to list_projects and search_principals give concrete guidance for finding required parameter values.

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