Skip to main content
Glama

Manage agenda and backlog items in a meeting. Use this when the user wants to add, update, remove, or schedule an agenda or backlog item. Do not use it to manage the meeting itself, participants, or action items — those are handled by separate tools. Set `backlog` to select the variant and `action` to one of: assign, create, delete, update. Then provide the fields for the selected combination. backlog=false, action=create: Add an item to a meeting's agenda. Use this when the user wants to schedule an agenda item. `meeting_id`, `title`, and `item_type` are required. A 409 means the meeting has already ended and cannot accept more agenda items; do not retry. The 201 body returns the created item `id`. Use an `Idempotency-Key` to prevent duplicates. backlog=false, action=delete: Remove an item from a meeting's agenda. Use this when the user wants to delete an agenda item. Deletes an agenda item in the caller's workspace, keyed by the `{id}` from v1ListAgendaItems; requires the `meetings:write` scope. Returns 204 No Content on success with no body. Deleting an unknown id or one outside the caller's workspace returns 404. The operation is effectively idempotent — a repeat delete of the same id simply 404s — so retries after a network error are safe. backlog=false, action=update: Modify an agenda item in a meeting. Use this when the user wants to change an item's title, description, or time allocation. Partial update (PATCH) of an agenda item. Requires `meetings:write` and the `id` from v1ListAgendaItems. 404 for unknown/cross-workspace ids. Not idempotent — re-read before retrying. `DEFERRED` skips the item in the current run; it does NOT move to the backlog. To move to backlog, delete and create a backlog item. backlog=true, action=assign: Schedule an unscheduled agenda item onto a meeting. Use this when the user wants to move a backlog item onto a meeting's agenda. Schedules an active backlog item onto a meeting. Requires `meeting_id` body field and `meetings:write` scope. Returns the new `agenda_item_id`; the backlog item is closed out and moves to v1ListBacklogItemHistory. Edit the created agenda item with v1UpdateAgendaItem. 404 unknown/out-of-workspace meeting, 400 missing `meeting_id`. backlog=true, action=create: Capture an unscheduled agenda item in the backlog. Use this when the user wants to save an item for later without putting it on a meeting. `title` and `item_type` are required; valid values are `DISCUSSION`, `QUESTIONS_TO_ANSWER`, `BREAK`, and `ADJOURN`. No `meeting_id` is used; assign to a meeting later with v1AssignBacklogItem. The 201 body returns the new `id`; use an `Idempotency-Key` to avoid duplicates. backlog=true, action=delete: Discard an unscheduled agenda item from the backlog. Use this when the user wants to permanently remove a backlog item. Soft-deletes the active backlog item keyed by `{id}`; removed items move to v1ListBacklogItemHistory with `deleted_at` set. Returns 204. There is no restore operation. The call is effectively idempotent: a repeat delete 404s, so retries are safe. backlog=true, action=update: Edit an unscheduled agenda item in the backlog. Use this when the user wants to change a backlog item's content. Partial update (PATCH) of an active backlog item. Omitted fields are left as-is; empty values clear the field. `item_type` is restricted to `DISCUSSION`, `QUESTIONS_TO_ANSWER`, `BREAK`, and `ADJOURN`. Already-assigned or deleted items return 404; find them in v1ListBacklogItemHistory.

manageMeetingItems
Destructive

Manage agenda and backlog items in a meeting. Use this when the user wants to add, update, remove, or schedule an agenda or backlog item. Do not use it to manage the meeting itself, participants, or action items — those are handled by separate tools.

Set backlog to select the variant and action to one of: assign, create, delete, update. Then provide the fields for the selected combination.

backlog=false, action=create: Add an item to a meeting's agenda. Use this when the user wants to schedule an agenda item.

meeting_id, title, and item_type are required. A 409 means the meeting has already ended and cannot accept more agenda items; do not retry. The 201 body returns the created item id. Use an Idempotency-Key to prevent duplicates.

backlog=false, action=delete: Remove an item from a meeting's agenda. Use this when the user wants to delete an agenda item.

Deletes an agenda item in the caller's workspace, keyed by the {id} from v1ListAgendaItems; requires the meetings:write scope. Returns 204 No Content on success with no body. Deleting an unknown id or one outside the caller's workspace returns 404. The operation is effectively idempotent — a repeat delete of the same id simply 404s — so retries after a network error are safe.

backlog=false, action=update: Modify an agenda item in a meeting. Use this when the user wants to change an item's title, description, or time allocation.

Partial update (PATCH) of an agenda item. Requires meetings:write and the id from v1ListAgendaItems. 404 for unknown/cross-workspace ids. Not idempotent — re-read before retrying. DEFERRED skips the item in the current run; it does NOT move to the backlog. To move to backlog, delete and create a backlog item.

backlog=true, action=assign: Schedule an unscheduled agenda item onto a meeting. Use this when the user wants to move a backlog item onto a meeting's agenda.

Schedules an active backlog item onto a meeting. Requires meeting_id body field and meetings:write scope. Returns the new agenda_item_id; the backlog item is closed out and moves to v1ListBacklogItemHistory. Edit the created agenda item with v1UpdateAgendaItem. 404 unknown/out-of-workspace meeting, 400 missing meeting_id.

backlog=true, action=create: Capture an unscheduled agenda item in the backlog. Use this when the user wants to save an item for later without putting it on a meeting.

title and item_type are required; valid values are DISCUSSION, QUESTIONS_TO_ANSWER, BREAK, and ADJOURN. No meeting_id is used; assign to a meeting later with v1AssignBacklogItem. The 201 body returns the new id; use an Idempotency-Key to avoid duplicates.

backlog=true, action=delete: Discard an unscheduled agenda item from the backlog. Use this when the user wants to permanently remove a backlog item.

Soft-deletes the active backlog item keyed by {id}; removed items move to v1ListBacklogItemHistory with deleted_at set. Returns 204. There is no restore operation. The call is effectively idempotent: a repeat delete 404s, so retries are safe.

backlog=true, action=update: Edit an unscheduled agenda item in the backlog. Use this when the user wants to change a backlog item's content.

Partial update (PATCH) of an active backlog item. Omitted fields are left as-is; empty values clear the field. item_type is restricted to DISCUSSION, QUESTIONS_TO_ANSWER, BREAK, and ADJOURN. Already-assigned or deleted items return 404; find them in v1ListBacklogItemHistory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoAgenda item ID
titleNoAgenda item heading (1-255 characters)
actionYesThe operation to perform
statusNoNew progress status: ACTIVE, COMPLETE, PENDING, FOCUSED, DEFERRED or SKIPPED
backlogNoSet to true for backlog items; omit or set to false for agenda items.
sequenceNoNumeric ordering key within the meeting agenda, ascending; appended last when omitted
item_typeNoKind of agenda item: DISCUSSION, QUESTIONS_TO_ANSWER, BREAK or ADJOURN
meeting_idNoID of the meeting to add the agenda item to
presentersNoUser IDs of the meeting participants presenting the item (max 50)
descriptionNoLonger description of the agenda item, in Markdown (max 5000 characters)
talking_pointsNoPrivate talking points for the authenticated user on this item, visible only to them, in Markdown (max 10000 characters)
Idempotency-KeyNoOptional client-generated idempotency key (max 255 printable ASCII). Repeat requests with the same key replay the original 2xx response.
time_allocation_minutesNoMinutes budgeted for the item (0-1440); 0 marks the item untimed

TDQS

A4.2/5.0
Behavior5/5

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

The description considerably enriches the annotations. It details which operations are effectively idempotent (delete), which are not (update), required scopes (meetings:write), soft-delete behavior with historical tracking, and what DEFERRED does (skips, does not move to backlog). This goes well beyond the destructiveHint and idempotentHint flags, providing concrete behavioral detail.

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 long but highly structured with a general overview, variant selector explanation, and seven distinct operation blocks. Every sentence adds value. Front-loading is good. The length is justified by the combinatorial complexity, but a slightly more concise generalization could reduce verbosity while maintaining clarity.

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?

The description is self-contained for an AI agent. It covers all seven operation combinations, required parameters, expected HTTP status codes, return bodies, idempotency details, scope requirements, and cross-links to related tools (v1ListAgendaItems, v1AssignBacklogItem). With no output schema, the description sufficiently explains return values and error cases.

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?

Despite 100% schema coverage, the description adds critical semantic context: which parameters are required per operation, valid item_type values, the role of backlog/action as selectors, and cross-references to other tools for IDs. It explains constraints like presenters max 50 and Idempotency-Key usage beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

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 comprehensive when-to-use guidance for each backlog/action combination, clearly delineates from alternatives ('those are handled by separate tools'), and includes error handling directives (e.g., 409 means meeting ended, do not retry; 404 meaning unknown id). It also advises on idempotency retries and required scopes. No gaps.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Tools are mostly distinct, with clear separation between meetings, agenda/backlog items, action items, participants, and calendar events. However, `manageMeetingContent` bundles both raw file attachments and AI context documents into one tool, which could cause confusion for an agent deciding which contentType variant to use.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern (e.g., `listMeetings`, `getMeeting`, `deleteUserToken`), but there are minor deviations like `manageMeetingItems` (verb_noun) vs `manageActionItems` (verb_noun) and `getMeetingTranscript` which is consistent, but `getMe` breaks the pattern as a short form. Overall, predictable and well-organized.

Tool Count4/5

With 30 tools, the count is on the higher side but reasonable given the broad domain covering meetings, agenda, backlogs, action items, participants, calendar events, user tokens, and content management. Each tool serves a specific purpose, though a slight reduction by combining some closely related functions could improve focus.

Completeness4/5

The tool surface covers the core lifecycle for meetings, agenda/backlog items, action items, participants, and content management. Minor gaps exist, such as the lack of tools for managing meeting templates (only listed, not created/deleted) and no tool for sending invitations via email, but these are not critical for the main use cases.

Resources