Skip to main content
Glama

Get meeting

get_meeting
Read-onlyIdempotent

Retrieve a meeting's complete details, including participants, agenda, and outcomes, to see what was discussed and decided.

Instructions

Read one meeting in full: participants, the agenda, and any recorded outcomes.

This is the "what was discussed / what was decided" call. It returns the meeting fields (title, project, start_time, end_time, duration_hours, location, state, author, timestamps), the invited participants as {id, name} refs, and agenda_items in agenda order — each with its title, notes (markdown), duration_minutes, presenter, the work_package it discusses, its section, and the outcomes recorded against it (kind, notes, author, linked work package).

Pitfalls. A work-package agenda item carries an empty title — the work package's subject is what the UI shows, so read work_package.name. When the linked work package is invisible to this account, work_package is null and notes says so; do not report the item as unlinked. If the agenda itself cannot be read (403/404 on the sub-resource), agenda_items is empty and notes explains why — an empty agenda and an unreadable one are different answers. Attendance, minutes as a document, and meeting sections' own titles beyond the item link are not exposed by API v3.

Cross-references: add_meeting_agenda_item to extend the agenda; list_meetings for the id; list_attachments(container_type='meeting', container_id=<meeting id>) for files; get_work_package for a linked ticket. update_meeting / delete_meeting change or remove the meeting itself — the result's lock_version is what update_meeting echoes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
meeting_idYesNumeric meeting id from list_meetings (it is also the number in a /meetings/<id> UI URL). Never a project id or an agenda item 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 (readOnlyHint, idempotentHint, destructiveHint), the description discloses important edge-case behaviors: empty title for work-package agenda items, null work_package when invisible, and the distinction between an empty agenda vs. an unreadable one (agenda_items empty with explanation). It also states API v3 limitations, adding significant transparency.

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 longer than typical but well-structured: it starts with the core purpose, then details return fields, then pitfalls, then cross-references. Every section provides value, especially the subtle edge cases. However, the enumeration of return fields may be redundant given the output schema exists, and the prose is dense. Still, it earns its length, so 4.

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 (meeting data with agenda items, outcomes, visibility nuances) and the presence of an output schema, the description is remarkably complete. It covers return values, edge cases (empty title, invisible work packages, unreadable agendas), API limitations, and related tools, leaving no obvious gaps for an agent to misuse the tool.

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 input schema already fully describes meeting_id (numeric id from list_meetings, not a project or agenda item id), so schema coverage is 100%. The description adds the cross-reference 'list_meetings for the id' and the note about lock_version for update_meeting, but it does not add new semantics for the parameter beyond what the schema provides. At baseline, a 3 is appropriate.

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: 'Read one meeting in full: participants, the agenda, and any recorded outcomes.' It clearly distinguishes the tool from siblings by naming alternatives in cross-references (add_meeting_agenda_item, list_meetings, update_meeting, delete_meeting), making its purpose unambiguous.

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 ('This is the "what was discussed / what was decided" call') and gives alternatives with clear purposes: 'list_meetings for the id', 'update_meeting / delete_meeting change or remove the meeting itself.' It also notes what is NOT exposed (attendance, minutes, section titles), helping the agent decide when not to use this tool.

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