Skip to main content
Glama

Make a booking link

booking_links_create

Make a booking link - a scheduling link offering times free_times_find found for a named meeting - for the person to send to one guest. The guest, with no account, picks one of these times in their own time zone and gives a name and address; the time is checked again against every calendar and the person's working hours, buffers, notice and daily maximum, and booked once, in the calendar the person named to receive bookings; a time no longer free is replaced by others up to the link's last, within those hours - Monday to Friday 09:00-17:00 where they stored none. The answer names the link's id and when it closes, 14 days after it is made, and a time after then is refused. The page a guest opens names nobody but the meeting, so subject is all a guest reads of whose meeting it is, e.g. Intro call with Sam Lee. An event holds its time as its provider's own free/busy shows it: on Google unless shown as available or declined - an invitation not yet answered or answered maybe included - on iCloud or a calendar server unless shown free or declined, and on Outlook only when shown busy or away, so an Outlook tentative answer leaves its time free; a cancelled event holds none.

Input Schema

NameRequiredDescriptionDefault
timesYesEach time offered, its start with its offset.
minutesNoMeeting length in minutes; the stored one where omitted.
subjectYesThe meeting's name, as whoever opens the link reads it.
guestZoneNoThe time zone of the guest the link is for, only as the person names it; the answer gives each time in it under guest too.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

The annotations say this is a non-read-only, open-world, non-destructive creation tool, and the description adds substantial context beyond that: the link expires after 14 days, the guest has no account, times are rechecked against calendars and working hours, fallback hours are Monday-Friday 09:00-17:00, and event busy/free semantics differ by provider. These details materially help an agent understand the tool's side effects and edge cases.

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

Conciseness2/5

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

The purpose is front-loaded, but the description is a dense, run-on block with long sentences covering calendar-provider semantics and guest-page behavior. Much of this is useful but not concise, and it would be difficult to scan quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with no output schema, the description covers the important return information (the link id and its 14-day closing time), the guest experience, revalidation behavior, and calendar hold semantics. It is substantially complete, though error cases and permission requirements are not addressed.

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%, so the schema already documents all four parameters well. The description reinforces that times come from free_times_find and that subject is the only meeting name a guest sees, but it adds little beyond the schema's own parameter descriptions.

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

Purpose4/5

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

The description states a specific verb and resource: making a booking link that offers times found by free_times_find for a named meeting, sent to one guest. It clearly identifies the sibling free_times_find as the source of times, though it does not explicitly contrast with other creation siblings such as polls_create or booking_page_set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for use: after free_times_find has produced times, for a single guest, with the guest picking in their own time zone. It does not explicitly state when not to use it or name alternative tools, but the intended workflow is clear.

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.