Skip to main content
Glama

Contio MeetingOS

by ai.contio

Create, update, and delete meetings in the workspace. Use this when the user wants to schedule, edit, or cancel a meeting. To manage participants, agenda/backlog items, or action items, use those dedicated tools. Set `action` to one of: create, delete, update. Then provide the fields for the selected action. action=create: Start a new meeting in the workspace. Use this when the user wants to schedule a meeting; the caller is added as owner automatically. Only `title` is required. `start_time` and `end_time` are optional ISO-8601; set `is_instant: true` for an ad-hoc meeting starting now. The caller is added as owner, so do not re-add them via v1AddMeetingParticipants. Returns 201 with the meeting `id`; use an `Idempotency-Key` to prevent duplicates. action=delete: Remove a meeting owned by the caller. Use this when the user wants to cancel or delete a meeting. Soft-deletes a meeting keyed by `{id}`; only the owner may delete it (403 for non-owners). Unknown or inaccessible ids return 404. Returns 204. The call is effectively idempotent: a repeat delete 404s, so retries are safe. action=update: Modify an existing meeting. Use this when the user wants to change a meeting's fields such as title or time. Partial update (PATCH) of a workspace-owned meeting. Omitted fields are left untouched. `start_time`/`end_time` are ISO-8601 with timezone; nulling start makes the meeting untimed and end open-ended. `end_time` must follow the effective start. Body must contain at least one field. 404/403/402 for unknown/inaccessible, no edit access, or plan-gated `template_id`.

manageMeetings
DestructiveIdempotent

Create, update, and delete meetings in the workspace. Use this when the user wants to schedule, edit, or cancel a meeting. To manage participants, agenda/backlog items, or action items, use those dedicated tools.

Set action to one of: create, delete, update. Then provide the fields for the selected action.

action=create: Start a new meeting in the workspace. Use this when the user wants to schedule a meeting; the caller is added as owner automatically.

Only title is required. start_time and end_time are optional ISO-8601; set is_instant: true for an ad-hoc meeting starting now. The caller is added as owner, so do not re-add them via v1AddMeetingParticipants. Returns 201 with the meeting id; use an Idempotency-Key to prevent duplicates.

action=delete: Remove a meeting owned by the caller. Use this when the user wants to cancel or delete a meeting.

Soft-deletes a meeting keyed by {id}; only the owner may delete it (403 for non-owners). Unknown or inaccessible ids return 404. Returns 204. The call is effectively idempotent: a repeat delete 404s, so retries are safe.

action=update: Modify an existing meeting. Use this when the user wants to change a meeting's fields such as title or time.

Partial update (PATCH) of a workspace-owned meeting. Omitted fields are left untouched. start_time/end_time are ISO-8601 with timezone; nulling start makes the meeting untimed and end open-ended. end_time must follow the effective start. Body must contain at least one field. 404/403/402 for unknown/inaccessible, no edit access, or plan-gated template_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoMeeting ID
titleNoMeeting title (1-255 characters)
actionYesThe operation to perform
end_timeNoScheduled end, ISO 8601 with timezone; omit to leave the meeting open-ended
is_instantNoCreates the meeting as an instant (start-now) meeting rather than a scheduled one
start_timeNoScheduled start, ISO 8601 with timezone; omit to create an untimed meeting
template_idNoID of the meeting template to seed the agenda from
detail_levelNoVerbosity of the generated meeting summary: BULLET_POINTS, STANDARD or VERBATIM
Idempotency-KeyNoOptional client-generated idempotency key (max 255 printable ASCII). Repeat requests with the same key replay the original 2xx response.

TDQS

A4/5.0
Behavior5/5

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

Annotations indicate idempotentHint=true and destructiveHint=true. The description goes well beyond by detailing exactly what happens for each action: create returns 201 with an id and the caller is auto-added as owner; delete is soft and returns 204/404/403; update is a PATCH with partial update semantics. It also explains error codes (403, 404, 402) and idempotency behavior for deletes. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear action sections and uses bullet-like formatting. It is moderately lengthy but every sentence adds value. Minor redundancy in repeating 'Use this when...' for each action could be tightened, but overall it's efficient and front-loaded with the main purpose.

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?

With 9 parameters and no output schema, the description comprehensively covers return codes (201, 204, 403, 404, 402), behavioral nuances for each action, and idempotency handling. The annotations handle safety, and the description fills in all remaining context. No gaps are apparent for an agent to misuse this tool.

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%, so each parameter already has a description. The description adds value by grouping parameters per action, explaining behavioral nuances (e.g., 'nulling start makes the meeting untimed'), and clarifying conditional requirements like is_instant for create. It could have explained detail_level and template_id more, but given schema already covers them, a 4 is appropriate.

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 when-to-use guidance for each action (e.g., 'Use this when the user wants to cancel or delete a meeting'). It also tells the agent NOT to re-add the owner via v1AddMeetingParticipants when creating, and suggests using Idempotency-Key to prevent duplicates. Alternatives are named ('use those dedicated tools') for participants, agenda/backlog items, and action items.

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

All Contio MeetingOS toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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