Skip to main content
Glama

Propose meeting

propose_meeting

Create the meeting: places one tentative, opaque hold per (slot × host) on the host's calendar — reversible, invisible to the invitee, auto-released on expiry — and STAGES the invitee's pick-a-time email. This tool itself NEVER emails anyone. BEFORE calling, topic AND agenda MUST be confirmed with the user in chat (ONE confirmation: "Good to go, or want to tweak?") — the invitee reads both on the invite they receive after picking. Keep names OUT of the topic ("Intro call", not "Call with Sarah"); write the agenda in second person to the invitee. slots: exactly 3, passed back verbatim from find_times (opaque ISO identifiers — never reformat them); pass deliberately busy slots' starts_at in busy_override_starts so they are kept. co_host_emails is for WORKSPACE MEMBERS only (holds land on their calendars too); the invitee goes in invitee_email, CCs in additional_invitee_emails; a non-member matching a known contact is dropped (dropped_co_hosts) — relay it. Link account_id / contact_id / opportunity_id when known (resolve via search first; never invent ids). AFTER calling: it returns the meeting's full state, picker_url and staged_invite_preview. The user's go-ahead on the content was already the authorization to send, so in the SAME turn call send_meeting_invite — do NOT ask a second time and do NOT treat staging as a separate approval gate. Withhold the send ONLY if the user explicitly said to hold it (then show staged_invite_preview and wait) or in shareable mode (no invitee_email — hand over picker_url). Never send without a clear human go. Full choreography and signed_in_as: capable://guide/scheduling.

When to use: After find_times, once the user has okayed the topic + agenda. Holds land on every host's calendar and the invite is staged; the content okay is the go-ahead, so call send_meeting_invite in the same turn unless the user said to hold it.

Example: Set up the meeting with those three times — topic and agenda as we agreed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotsYesExactly 3 slots, byte-identical from find_times output.
topicYesShort subject — becomes the calendar invite title and the picker heading. E.g. "Intro call", "Portfolio review", "Partnership next steps". No participant names.
agendaYesGoes into the calendar event description; the invitee reads it. Second person, 2–4 sentences, no invitee name.
account_idNoLink the meeting to an account in your workspace.
contact_idNoLink the meeting to a contact (usually the invitee).
window_endNoForward the window_end you gave find_times (ISO 8601) — stored with window_start as the meeting's search window for reschedule context.
duration_minYesMeeting duration in minutes — must match the find_times call.
invitee_nameYesPrimary invitee's full name.
window_startNoForward the window_start you gave find_times (reschedule context).
invitee_emailNoPrimary invitee's email. OMIT for shareable mode — the picker URL comes back for the user to share manually, and the invitee enters their email when they pick.
co_host_emailsNoWORKSPACE MEMBERS who co-host: holds land on their calendars too, and the confirmed event includes them. WORKSPACE MEMBERS ONLY — never the external invitee (the invitee goes in invitee_email / additional_invitee_emails, not here). A non-member address that matches a known workspace contact is dropped and the meeting is created without it.
opportunity_idNoLink the meeting to an opportunity.
invitee_companyNoPrimary invitee's company name, stored on the meeting; it appears in the host's booked notification and is matched by meeting search.
expiration_hoursNoHours before the held times auto-release if the invitee doesn't pick. Defaults to the host's saved default.
busy_override_startsNoISO `starts_at` values (from `slots`) that the host DELIBERATELY chose over a busy time on their (or a co-host's) calendar — the find_times card flags these with `busy_override` after the host drops a slot onto a visible busy band. Pass them here ONLY after you've given the user a heads-up (a light note for the host's own busy; a STRONGER one — "only if you've cleared it with them" — for a co-host's). A start in this list is kept-while-busy (its hold is placed and honored at the invitee's confirm); a busy slot NOT in this list is a race and is dropped. Omit when no slot overrides a busy time.
additional_invitee_emailsNoSecondary invitees — CC'd on the picker email and added to the calendar event; only the primary invitee picks. Requires invitee_email.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
slotsNo
meetingNo
guidanceNo
proposedNo
timed_outNo
picker_urlNo
signed_in_asNo
dropped_slotsNo
repairs_flaggedNo
dropped_co_hostsNo
staged_invite_previewNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this non-readOnly, non-idempotent, open-world, non-destructive, but the description adds substantially beyond them: holds are tentative/opaque/reversible/auto-released on expiry, "this tool itself NEVER emails anyone," the drop-and-relay edge case for non-member co-hosts, and the authorization semantics (the content okay IS the go-ahead). Rich, non-redundant behavioral disclosure.

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?

Long for a description, but front-loaded with the highest-value facts (holds, never-emails, authorization) and each paragraph encodes a distinct rule rather than filler. The separate "When to use" block partially restates the opening, which is the main redundancy cost.

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?

For a 16-parameter, multi-step scheduling tool the description covers sequencing (find_times → propose → same-turn send), edge cases (shareable mode, hold-it case, dropped co-hosts), and authorization. Output schema exists, so return values need not be described — the completeness bar is met.

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 description coverage is 100%, so the schema already documents most parameters in detail; much of the description's param text (names out of topic, second-person agenda, workspace-members-only co-hosts, byte-identical slots) duplicates it. The additive value is the workflow guidance not in the schema: relay dropped_co_hosts, resolve ids via search first / never invent them, and the busy_override heads-up protocol.

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?

States a specific verb+resource ("Create the meeting") and immediately qualifies scope: places tentative, opaque, reversible holds per (slot × host) and STAGES the invitee's pick-a-time email. This clearly distinguishes it from find_times (upstream) and send_meeting_invite (the separate send step), which it explicitly warns never happens here.

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?

Explicit when-to-use: "After find_times, once the user has okayed the topic + agenda." Gives the when-not/alternative path too: withhold the send only if the user said to hold it or in shareable mode. Nothing is left to inference, and the mandatory confirmation gate is spelled out.

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.

Resources