Skip to main content
Glama

List meetings

list_meetings
Read-onlyIdempotent

List a project's scheduled and past meetings with times, locations, and IDs. Find upcoming meetings or retrieve a meeting ID to access details and agenda items.

Instructions

List meetings — the schedule side of a project: what is coming up, what already ran.

Use it to answer "when do we next meet", "what meetings does this project have", or to find the meeting id that get_meeting and add_meeting_agenda_item need. Meeting ids are instance-wide and never guessable, so this is the way to get one.

Returns the standard list envelope: rows of {id, title, project, start_time, end_time, duration_hours, location, state} plus pagination and notes. Times are ISO 8601 UTC and duration_hours is a float (1.5 = 90 minutes). Rows are ordered by start time — ascending when upcoming_only, descending otherwise.

Pitfalls. Cancelled meetings and recurring-series templates are excluded upstream, so an absent meeting may exist in another state. state of 'draft' means the meeting has not been opened to its participants yet. Agenda items and participants are NOT in these rows; get_meeting fetches them. Meetings are a module: when it is not installed here or not enabled in the project (404), or this account may not read meetings (403), the call still SUCCEEDS with an empty items and the reason in notes — read notes before saying a project has no meetings, because an empty list with a note is not an empty schedule.

Cross-references: get_meeting(meeting_id=...) for participants, agenda and outcomes; create_meeting to schedule one; list_projects for the project id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number.
page_sizeNoMeetings per page (max 100).
project_idNoNumeric project id to list only that project's meetings, from list_projects. Unlike most project parameters this one takes the id only — the meetings filter rejects a URL identifier, and passing one fails immediately with that explanation. Omit for every meeting visible to you.
upcoming_onlyNoTrue (the default) lists meetings that have not finished yet, soonest first. False lists past meetings too, most recent first — use it for 'what did we discuss last week'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.
Behavior5/5

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

The description goes well beyond the annotations (readOnlyHint, idempotentHint) by disclosing several behavioral traits: return envelope fields, ISO 8601 UTC format, ordering rules, exclusion of cancelled/recurring templates, the meaning of 'draft' state, and the critical silent-success behavior when meetings module is unavailable (empty items with reason in notes). It also warns that absence may not mean no meetings, which is essential for correct interpretation.

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 and front-loaded: first sentence states purpose, followed by usage, return format, pitfalls, and cross-references. Though lengthy, every sentence carries relevant information—no filler. The 'Pitfalls' section is clearly demarcated, improving readability and scanability.

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 (module behavior, silent failures, ordering, exclusions) and the moderate schema/annotations, the description covers all essential aspects: output format, time zone, ordering, edge cases, and error-like conditions. The output schema covers return structure, so the description compensates for any remaining ambiguity about behavioral nuances.

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% with each parameter described, so the baseline is 3. The description adds extra semantics: it clarifies that project_id takes only the numeric ID (rejecting URL identifiers) and explains the ordering behavior tied to upcoming_only. While these are refinements, they add useful meaning beyond the schema's own descriptions.

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 clearly states the tool lists meetings, the schedule side of a project, and explicitly distinguishes it from related tools like get_meeting and create_meeting. It also gives concrete use cases ('when do we next meet', 'what meetings does this project have'), making the 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 when-to-use guidance: it says to use it to find meeting IDs needed by get_meeting and add_meeting_agenda_item, and to answer schedule questions. It also names alternatives (get_meeting for participants/agenda, create_meeting to schedule, list_projects for project IDs), fulfilling the when-not and alternative criteria.

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