Skip to main content
Glama

Set up a booking page

booking_page_set
DestructiveIdempotent

Set one of the person's permanent booking pages - a scheduling page anyone can book a time from - named by the name it answers at on this site: the one they hold by that name changes in the fields given alone, newName moving it to a new address while its old one answers nothing; a name they hold no page by adds a page, which needs subject and stays until the account goes. Anyone opening a page, with no account, sees up to 20 times free in every calendar within the person's working hours - Monday to Friday 09:00-17:00 where they stored none - and every other preference, spread across the coming 14 days, each day's preferred times first, in their own time zone, and books one by giving a name and address, in the calendar the person named to receive bookings; a time is booked once across all their pages. 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
nameYesThe page's name in its address: 3 to 40 lowercase letters, digits and hyphens.
minutesNoMeeting length in minutes; for a new page the stored one where omitted.
newNameNoA new name for the page named, which its address then carries.
subjectNoThe meeting's name, as the guest reads it; a new page needs it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the annotations, the description adds valuable behavioral context: renaming moves the page and leaves the old address answering nothing, a new page needs subject, and updates affect only the fields given. It also explains guest-facing booking behavior and calendar free/busy interpretation, though it does not clarify permissions or precisely what destructiveHint means here.

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 description is a dense, run-on construction that mixes the tool's invocation semantics with extensive background about guest booking, working hours, time zones, and provider free/busy rules. The purpose is front-loaded, but the text is far longer and harder to parse than necessary for calling this four-parameter tool.

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 complex mutation tool with no output schema, the description covers the important create/update distinction, rename side effect, subject requirement, and guest-visible behavior. It omits permission/auth details and some sibling-routing guidance, but it provides enough context to invoke the tool correctly.

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 already 100%, so the baseline is 3, but the description adds meaning for name, newName, and subject beyond the schema, especially that newName moves the address and that subject is the only identifying text a guest reads. It does not add similar meaning for minutes, which the schema explains adequately.

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 action and resource: setting one of the person's permanent booking pages, including creating or modifying a page by name. It also makes the update-versus-create distinction clear through the existing-name and new-name cases, though the phrasing is tangled enough that it does not cleanly separate itself from sibling tools such as booking_links_create.

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

Usage Guidelines2/5

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

It gives behavioral conditions, such as a held name modifying an existing page and an unused name adding a page, but it does not say when an agent should use this tool instead of alternatives like booking_links_create or polls_create. There is no explicit usage guidance or exclusion criteria against siblings.

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.