Skip to main content
Glama

List meeting slots by trip

well_list_meeting_slots
Read-only

List the times one meeting at a place can take, from free time and trip times already read. Call it after well_find_free_time and after the well_get_travel_time calls between the meeting place and each of the person's own events that has a place. Pass slots and timezone as well_find_free_time returned them, and meeting_minutes. In events, pass each of the person's own events that has a place, with start_at and end_at as well_list_calendar_events returned them, is_all_day as it returned it, minutes_to_meeting (the trip from the event's place to the meeting place) and minutes_from_meeting (the trip from the meeting place to the event's place). Each trip is the duration_minutes the travel read returned, or null when it returned no_route or was not called. Leave out events with no place.

For each slot, the trips that count are to the last event with a place that ends before it on its day and from the first one that starts after it on its day, so read those trips. An all-day event sets no trip, and an event that ends at midnight counts on the day before that midnight. Time outside the free slots is busy, so a trip is made outside the slot only when one free slot between that event and the slot holds the whole trip; otherwise the whole trip comes off the slot. The tool reads nothing and calls no service.

It returns meeting_slots in this order: slots next to a checked trip, shortest trip first; then slots with no event with a place next to them; then slots whose trip was not checked. trip_status is "checked", "no_event" or "not_checked". Each slot keeps its trips as margins and starts or ends on a 5-minute mark when such a time fits; else it starts at the first free minute after the trip. When trip_status is "checked", trip_minutes is the trip of the event the slot is placed against, as given, and trip_event_start_at is that event's start_at; when no time on a 5-minute mark fits, both come from the smaller checked trip of the slot's two edges (the trip before it on a tie). Otherwise both are null. dropped_slots counts free slots too short for the meeting and its trips. On success false, error_reason is "unknown_time_zone" or "invalid_range" (a slot or an event that does not end after it starts).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
slotsYesThe free slots from well_find_free_time, passed as it returned them.
eventsYesThe person's own events that have a place. Leave out events with no place.
timezoneYesThe IANA time zone of the slots, as well_find_free_time returned it.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
meeting_minutesYesHow long the meeting lasts, in minutes.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
successYes
timezoneYes
error_reasonNo
dropped_slotsYes
meeting_slotsYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare readOnlyHint/openWorldHint/destructiveHint; the description goes further by stating 'The tool reads nothing and calls no service', how unchecked trips are treated, the result ordering, trip_status values, dropped_slots, and the two failure reasons. The long detour into 5-minute rounding and tie-breaking is more return-format detail than behavioral guidance, but nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The prerequisite paragraph is well front-loaded, but the middle becomes a dense run-on of edge-case rules (midnight-ending events, all-day events, trip-outside-slot accounting, 5-minute mark tie-breaking) that is hard to parse in a single block. Several of those rules describe return-value formatting that the output schema could carry instead.

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 pure-computation tool with 7 parameters, a nested event shape, and an output schema, the description covers prerequisites, which trips must be read beforehand, error conditions, and workspace resolution. An agent has everything it needs to compose the call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and much of the description's parameter guidance (what minutes_to_meeting/minutes_from_meeting mean, null on no_route, leaving out placeless events) restates the property descriptions nearly verbatim. It does add the workflow-level meaning — that trips are keyed to the slot's nearest event on each edge — but with the schema already carrying the field semantics, this is baseline-level value.

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 and resource — 'List the times one meeting at a place can take' — and immediately scopes the input to 'free time and trip times already read', which cleanly separates it from the sibling tools that produce those inputs (well_find_free_time, well_get_travel_time). An agent can distinguish it from any sibling without opening the schema.

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?

Gives explicit ordering: call it after well_find_free_time and after the well_get_travel_time calls for the meeting place vs. each event with a place. It also states the workspace rule — call directly with one authorized workspace, pass workspace_id when several are authorized. Both when-to-use and preconditions are covered.

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