OpenProject CE MCP Server

Overview Schema Source Related Servers Discussions Admin

Update meeting

update_meeting

Reschedule, publish, start, close, or replace participants for a meeting. Only the fields you send are updated; omitted values remain unchanged.

Instructions

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

Reschedule ("move Thursday's review to 15:00"), publish a draft (state='open'), start/wrap up a running one (state='in_progress'/'closed'), or fix participants. Only passed parameters 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. 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 and retry deliberately. Needs 'edit meetings' permission; moving a meeting to another project isn't offered.

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`state`	No	New lifecycle state: 'open' publishes a draft to participants, 'in_progress' starts it (required before outcomes can be recorded), 'closed' freezes it, 'cancelled' calls it off.
`title`	No	New title. Omit to leave alone; cannot be cleared.
`location`	No	New room name or meeting URL; replaces the stored one. Null or an empty string clears it; omit to leave it untouched.	__unchanged__
`meeting_id`	Yes	Numeric meeting id from list_meetings or get_meeting (never a project or agenda item id).
`start_time`	No	New start as ISO 8601 with a timezone: '2026-08-03T14:00:00Z' or '...+02:00'. Offset-less times are rejected locally. Omit to keep the current time.
`lock_version`	No	The lock_version from get_meeting. Passing it makes a concurrent edit fail loudly (409); omitting it fetches and echoes the current version — safe, but a wider conflict window.
`participants`	No	Full new invite list (user ids), from search_principals or a project's memberships. Replaces the whole set — read the current list with get_meeting first and send it complete. Omit to leave untouched.
`duration_minutes`	No	New length in minutes (90 = 1.5 hours); the end time is derived from it. Omit to keep the current duration.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	Meeting id — what get_meeting and add_meeting_agenda_item take.
`notes`	No	Degradation notes: agenda items that could not be read, work packages this account may not see.
`state`	No	Lifecycle state: 'draft' (not yet opened to participants), 'open', 'in_progress', 'closed' or 'cancelled'. Cancelled meetings are excluded from listings.
`title`	No	Meeting title.
`author`	No	User who created the meeting.
`project`	No	Project the meeting belongs to.
`end_time`	No	ISO 8601 UTC end timestamp, derived from start plus duration.
`location`	No	Room name or meeting URL as typed by the organizer.
`created_at`	No	ISO 8601 UTC timestamp.
`start_time`	No	ISO 8601 UTC start timestamp; null for an undated meeting.
`updated_at`	No	ISO 8601 UTC timestamp.
`agenda_items`	No	The agenda in order; always a list. Empty means either no agenda or an unreadable one — check 'notes' before concluding the meeting had none.
`lock_version`	No	Optimistic-lock version. Echo it as update_meeting's lock_version so a concurrent edit fails loudly (409) instead of being overwritten.
`participants`	No	Invited users; always a list. Attendance is not exposed by API v3.
`duration_hours`	No	Scheduled length in hours (1.5 = 90 minutes); the wire sends an ISO duration, which is converted here.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.3.2Sep 24, 2026

changedInput schema / properties / duration_minutes / description

Previous value: -"New length in minutes (90 = one and a half hours); the end time is derived from it. Omit to keep the current duration."New value: +"New length in minutes (90 = 1.5 hours); the end time is derived from it. Omit to keep the current duration."

changedInput schema / properties / location / description

Previous value: -"New 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."New value: +"New room name or meeting URL; replaces the stored one. Null or an empty string clears it; omit to leave it untouched."

changedInput schema / properties / lock_version / description

Previous value: -"The 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."New value: +"The lock_version from get_meeting. Passing it makes a concurrent edit fail loudly (409); omitting it fetches and echoes the current version — safe, but a wider conflict window."

changedInput schema / properties / meeting_id / description

Previous value: -"Numeric meeting id from list_meetings or get_meeting. Never a project id or an agenda item id."New value: +"Numeric meeting id from list_meetings or get_meeting (never a project or agenda item id)."

changedInput schema / properties / participants / description

Previous value: -"User 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."New value: +"Full new invite list (user ids), from search_principals or a project's memberships. Replaces the whole set — read the current list with get_meeting first and send it complete. Omit to leave untouched."

changedInput schema / properties / start_time / description

Previous value: -"New 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."New value: +"New start as ISO 8601 with a timezone: '2026-08-03T14:00:00Z' or '...+02:00'. Offset-less times are rejected locally. Omit to keep the current time."

changedInput schema / properties / state / description

Previous value: -"New 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."New value: +"New lifecycle state: 'open' publishes a draft to participants, 'in_progress' starts it (required before outcomes can be recorded), 'closed' freezes it, 'cancelled' calls it off."

changedInput schema / properties / title / description

Previous value: -"New meeting title. Omit to leave it alone; it cannot be cleared."New value: +"New title. Omit to leave alone; cannot be cleared."

First observedv0.1.0Aug 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing partial-update semantics ('Only passed parameters are sent; omitted fields stay as they are'), the closed-meeting restriction, 409 conflict recovery, permission requirement ('Needs 'edit meetings' permission'), and return shape with fresh lock_version. These are behavioral traits not carried by readOnlyHint/openWorldHint/idempotentHint/destructiveHint. No contradiction with 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 longer than one or two sentences but earns its length: it front-loads the purpose, then uses 'Pitfalls.' and 'Cross-references:' headings to separate critical constraints from related tools. Code spans and examples keep the prose tight. No filler sentences.

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 an 8-parameter mutating tool with a 100%-covered schema and an output schema, the description covers the important non-schema context: lifecycle transitions, partial updates, closed-meeting limitations, conflict resolution, permissions, and relationship to get/create/delete/outcome tools. The scope statement excludes agenda items, so the lack of cross-references to update_meeting_agenda_item is not a meaningful gap. Complete enough.

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

Parameters4/5

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

Schema coverage is 100% and the schema already documents each parameter's omit/null behavior, so the baseline is 3. The description adds cross-cutting value—the partial-update rule, closed-meeting state-only patch, conflict/retry workflow, and concrete state usage examples—but overlaps with the schema's per-parameter descriptions. Therefore 4 rather than 5.

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.' This clearly distinguishes update_meeting from siblings like create_meeting, delete_meeting, and add_meeting_outcome, so an agent can select it unambiguously.

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 names cross-references: get_meeting for current values/lock_version, create_meeting to schedule a new one, delete_meeting to remove one, and add_meeting_outcome for what 'in_progress' unlocks. It also gives exclusions—closed meeting accepts only a state-only patch, moving a meeting to another project isn't offered—and warns to re-read and retry on 409. This is explicit when/when-not guidance.

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

Deploy Server