Skip to main content
Glama

Update meeting

update_meeting

Update a meeting's title, schedule, location, participants, or lifecycle state. Reschedule, publish drafts, start or close meetings in OpenProject.

Instructions

Change a meeting's title, time, place or invite list — or move its lifecycle state.

Use it to reschedule ("move Thursday's review to 15:00"), to publish a draft (state='open'), to start or wrap up a running one (state='in_progress' / 'closed' — outcomes can only be recorded while it is in progress), or to fix the participants. Only the parameters you pass are sent; omitted fields stay as they are.

Returns the updated meeting in the same shape as get_meeting, including the fresh lock_version for a follow-up edit.

Pitfalls. participants replaces the entire set — a partial list silently uninvites everyone else. A closed meeting accepts a state-only patch (reopening it) and nothing else; any other change is rejected with a validation error until it is reopened. A conflict error (409) means somebody edited the meeting since you read it — the error carries the fresh lock_version and the differing fields, so re-read, decide, retry deliberately. This needs the 'edit meetings' permission, and moving a meeting to another project is deliberately not offered.

Cross-references: get_meeting for the current values and the lock_version; create_meeting to schedule a new one; delete_meeting to remove one; add_meeting_outcome for what an 'in_progress' state unlocks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateNoNew lifecycle state: 'open' publishes a draft to its participants (exactly what the UI's publish does), 'in_progress' starts it (required before outcomes can be recorded), 'closed' freezes it, 'cancelled' calls it off. There is no dedicated state endpoint upstream — this plain field is it.
titleNoNew meeting title. Omit to leave it alone; it cannot be cleared.
locationNoNew room name or meeting URL; REPLACES the stored one. Pass null or an empty string to clear it. Omit the parameter entirely (the default) to leave it untouched.__unchanged__
meeting_idYesNumeric meeting id from list_meetings or get_meeting. Never a project id or an agenda item id.
start_timeNoNew start as ISO 8601 WITH a timezone: '2026-08-03T14:00:00Z' or '2026-08-03T16:00:00+02:00'. A time without an offset is rejected locally rather than booked in the wrong hour. Omit to keep the current time.
lock_versionNoThe lock_version you read from get_meeting. Pass it and the write fails loudly (409) if somebody else edited the meeting in the meantime. Omit it and the current version is fetched and echoed — still safe, just one more round trip and a slightly wider conflict window.
participantsNoUser ids of the FULL new invite list, from search_principals or a project's memberships. This REPLACES the whole set — anyone not listed is uninvited — so read the current list with get_meeting first and send it complete. Omit to leave the participants untouched.
duration_minutesNoNew length in minutes (90 = one and a half hours); the end time is derived from it. Omit to keep the current duration.

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?

Annotations already mark readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the write nature is known. The description adds substantial behavioral context beyond that: partial update semantics ("Only the parameters you pass are sent; omitted fields stay as they are"), participants replacement behavior ("a partial list silently uninvites everyone else"), closed-meeting restrictions, optimistic locking (409 conflict), and permission requirements. It even reveals upstream behavior ("no dedicated state endpoint upstream — this plain field is it") and return shape. 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.

Conciseness5/5

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

The description is well-structured with a clear first sentence, a practical "Use it to..." list, a note on return shape, and a "Pitfalls" section. It front-loads the core purpose, uses compact bullet-like semicolon-separated examples, and every sentence earns its place. Despite its length, it is dense with actionable information and avoids fluff.

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 (8 parameters, including lifecycle state transitions and concurrency controls) and the presence of an output schema, the description is remarkably complete. It covers usage scenarios, pitfalls, permission requirements, concurrency behavior, return value shape (referencing get_meeting), and what operations are deliberately not supported. The output schema handles return values, so the description's mention of the return shape is appropriate context, not redundancy.

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?

Schema description coverage is 100%, meaning every parameter already has a detailed schema description. However, the tool description adds further meaning beyond the schema: it explains the overall partial-update model (omitted fields unchanged), the significance of lock_version for concurrency control, the participants replacement pitfall, timezone requirements for start_time, and the "cannot be cleared" nuance for title. This enriches the agent's understanding beyond the schema alone.

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 and resource: "Change a meeting's title, time, place or invite list — or move its lifecycle state." It clearly distinguishes this from siblings like create_meeting, get_meeting, and delete_meeting by enumerating the mutable attributes and lifecycle states. The cross-references at the end explicitly name sibling tools, reinforcing differentiation.

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 provides explicit usage context: "Use it to reschedule..., to publish a draft..., to start or wrap up..." and gives concrete example invocations. It also states when not to use it (e.g., "moving a meeting to another project is deliberately not offered") and cross-references get_meeting, create_meeting, delete_meeting, and add_meeting_outcome for related operations. This is exemplary 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