Skip to main content
Glama

Upload, download, or remove raw file attachments and AI context documents for a meeting. Use `contentType=attachment` for binary files such as PDFs and images; use `contentType=context` for text-biased background material such as company profiles or meeting notes. To manage agenda or action items, use those dedicated tools. Set `contentType` to select the variant and `action` to one of: delete, download, upload. Then provide the fields for the selected combination. contentType=attachment, action=delete: Remove a raw file attachment from a meeting. Use this when the user wants to delete an uploaded file. Deletes an attachment (`{attachment_id}`) from a meeting (`{id}`) together with its stored bytes; requires the `meetings:write` scope. Irreversible. Only a caller with edit rights on the attachment may delete it (403 otherwise), and unknown or cross-meeting ids return 404. contentType=attachment, action=download: Get the raw file bytes of a meeting attachment. Use this when the user wants to retrieve a binary file. Returns the raw bytes of the attachment identified by meeting `{id}` and `{attachment_id}`. Through the MCP gateway the response is a JSON object with `base64`, `filename`, `mime_type`, and `size`. Link attachments return 400. Unknown or inaccessible ids return 404. contentType=attachment, action=upload: Attach a raw or binary file to a meeting. Use this when the user wants to upload a PDF, image, spreadsheet, or other non-text file as a raw attachment; for AI-readable text background material, use the context upload instead. Uploads a raw file to a meeting (`{id}`) as base64. Only `file` is required; `kind` accepts only `file`. Files are stored verbatim, capped at 50MB (413 if exceeded). The 201 body returns the attachment `id`. Not idempotent — retries upload again. contentType=context, action=delete: Remove an AI context document from a meeting. Use this when the user wants to delete background material; raw files are removed with the attachment delete instead. Soft-deletes the AI context document identified by meeting `{id}` and `{context_id}`. For raw file attachments use v1DeleteMeetingAttachment. Returns 204. The call is effectively idempotent: a repeat delete 404s, so retries are safe. contentType=context, action=download: Get the content of an AI context document. Use this when the user wants to retrieve background material; for raw files use the attachment download instead. Returns the stored content of the AI context document identified by meeting `{id}` and `{context_id}`. The sanitized/converted copy is returned when available, otherwise the original bytes. Use v1GetMeetingContext for metadata. Unknown or inaccessible ids return 404. contentType=context, action=upload: Add a text-biased background document the AI can reference. Use this when the user wants to upload company profiles, notes, transcripts, or other text context; it requires `source_format` such as `markdown`, `plain_text`, or `json`. For PDFs, images, and other binary files, use the attachment upload instead. Uploads text-biased material to a meeting. `file` must be base64-encoded; `file_name`/`file_type` override filename/MIME, otherwise `title`/`context_type` are used. `source_format` (e.g. `markdown`, `plain_text`, `json`) is required. Capped at 4.5MB; per-meeting cap may return 400. Not idempotent.

manageMeetingContent
Destructive

Upload, download, or remove raw file attachments and AI context documents for a meeting. Use contentType=attachment for binary files such as PDFs and images; use contentType=context for text-biased background material such as company profiles or meeting notes. To manage agenda or action items, use those dedicated tools.

Set contentType to select the variant and action to one of: delete, download, upload. Then provide the fields for the selected combination.

contentType=attachment, action=delete: Remove a raw file attachment from a meeting. Use this when the user wants to delete an uploaded file.

Deletes an attachment ({attachment_id}) from a meeting ({id}) together with its stored bytes; requires the meetings:write scope. Irreversible. Only a caller with edit rights on the attachment may delete it (403 otherwise), and unknown or cross-meeting ids return 404.

contentType=attachment, action=download: Get the raw file bytes of a meeting attachment. Use this when the user wants to retrieve a binary file.

Returns the raw bytes of the attachment identified by meeting {id} and {attachment_id}. Through the MCP gateway the response is a JSON object with base64, filename, mime_type, and size. Link attachments return 400. Unknown or inaccessible ids return 404.

contentType=attachment, action=upload: Attach a raw or binary file to a meeting. Use this when the user wants to upload a PDF, image, spreadsheet, or other non-text file as a raw attachment; for AI-readable text background material, use the context upload instead.

Uploads a raw file to a meeting ({id}) as base64. Only file is required; kind accepts only file. Files are stored verbatim, capped at 50MB (413 if exceeded). The 201 body returns the attachment id. Not idempotent — retries upload again.

contentType=context, action=delete: Remove an AI context document from a meeting. Use this when the user wants to delete background material; raw files are removed with the attachment delete instead.

Soft-deletes the AI context document identified by meeting {id} and {context_id}. For raw file attachments use v1DeleteMeetingAttachment. Returns 204. The call is effectively idempotent: a repeat delete 404s, so retries are safe.

contentType=context, action=download: Get the content of an AI context document. Use this when the user wants to retrieve background material; for raw files use the attachment download instead.

Returns the stored content of the AI context document identified by meeting {id} and {context_id}. The sanitized/converted copy is returned when available, otherwise the original bytes. Use v1GetMeetingContext for metadata. Unknown or inaccessible ids return 404.

contentType=context, action=upload: Add a text-biased background document the AI can reference. Use this when the user wants to upload company profiles, notes, transcripts, or other text context; it requires source_format such as markdown, plain_text, or json. For PDFs, images, and other binary files, use the attachment upload instead.

Uploads text-biased material to a meeting. file must be base64-encoded; file_name/file_type override filename/MIME, otherwise title/context_type are used. source_format (e.g. markdown, plain_text, json) is required. Capped at 4.5MB; per-meeting cap may return 400. Not idempotent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoMeeting ID
fileNoFile to attach (any MIME type, up to 50MB)
kindNoAttachment kind. Only file is currently creatable
titleNoDocument title
actionYesThe operation to perform
file_nameNoOptional filename for the uploaded file
file_typeNoOptional MIME type for the uploaded file
context_idNoContext ID
contentTypeNoThe contentType discriminator
access_levelNoWho may see the attachment
context_typeNoMIME type of the document
attachment_idNoAttachment ID
source_formatNoSource format (json, csv, tsv, xml, html, yaml, markdown, plain_text)

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already indicate destructive (destructiveHint=true) and non-idempotent (idempotentHint=false). The description adds rich behavioral context: required scope (meetings:write), irreversibility of delete, error codes (403, 404, 400, 413), size caps (50MB for attachments, 4.5MB for context), idempotency details for delete (404 on repeat), and response format for download. 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: a high-level summary followed by a clear breakdown of all six contentType-action pairs. Each variant includes a usage hint and technical details. Despite length, every sentence adds value, and the structure makes it easy to scan. No wasted words.

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 (13 parameters, 6 variants, no output schema), the description is exceptionally complete. It covers all combinations, error responses, size limits, idempotency, auth scope, and response format for download. The only minor gap is no explicit confirmation of delete response (204 implied), but it's still sufficient.

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 coverage is 100% (all parameters have descriptions). The description adds significant meaning: which parameters are required per combination, valid values (e.g., kind only accepts 'file', source_format required for context upload), and constraints (e.g., file must be base64). This far exceeds the schema alone.

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 explicit guidance on when to use each contentType-action combination, including alternative tools (e.g., 'for raw files use the attachment download instead'). It covers prerequisites, error scenarios, and trade-offs between attachment and context, giving clear when-to-use and when-not-to-use instructions.

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