Find open times and book, reschedule or cancel meetings on anyone's Tempi link. No account needed.
Scored across 8 tools
Each tool targets a distinct resource and action: profile lookup, availability, series checking, booking creation, booking retrieval, rescheduling, cancellation, and waitlist joining. The two availability tools are clearly separated by one-off vs. recurring series, and the two booking-modification tools are unambiguous in their verbs.
Tool names follow a consistent snake_case verb_noun pattern, with get_* used for queries and action verbs for mutations. The 'as_invitee' suffix on cancel and reschedule is applied consistently, and even check_series fits the readable verb_noun style.
Eight tools is well-scoped for an invitee-facing booking server. Each tool covers a necessary step in the booking journey without redundancy, and none feel like filler or overlap.
The core invitee lifecycle is covered: discover, check availability, create, view, reschedule, and cancel, plus series-specific availability and waitlist access. Minor gaps exist, such as no bulk listing of a user's bookings and no series-wide reschedule/cancel operation, but these are workable limitations rather than dead ends.
Cancels a booking by its id and token. The event is removed from the host's calendar. Paid bookings cancelled before refundableUntil are refunded in full. Later cancellations get no refund. The event type sets the rules, which get_booking shows: no changes after changeableUntil (409 change_too_late), no cancelling when canCancel is false (409 cancel_not_allowed, reschedule instead), and a reason when cancelReasonRequired is true (422 reason_required).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | a string at least 1 character(s) long | |
| token | Yes | a string at least 10 character(s) long | |
| reason | No | a string at most 500 character(s) long | |
| following | No | for a series: also cancel every later meeting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses concrete behavioral effects: the event is removed from the host's calendar, paid bookings are refunded only before refundableUntil, and specific error codes (409, 422) with their triggering conditions are listed. This far exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but every sentence earns its place: purpose, primary side effect, refund policy, and cancellation rules with alternatives. It is front-loaded with the core action and then adds necessary behavioral detail without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation tool with destructive effects, the description covers the essential context: required identifiers, side effects, refund consequences, error scenarios, and how to discover the rules via get_booking. The 4 parameters are either explained in the schema or enriched in the description, so an agent has enough to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that id and token identify the booking, that reason is required only when cancelReasonRequired is true, and that changeability constraints come from the event type. This elevates it above baseline, though the description doesn't elaborate on the 'following' parameter because the schema already documents it clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Cancels a booking by its id and token.' It clearly distinguishes this from the sibling reschedule_booking_as_invitee by mentioning the cancellation action and the alternative to reschedule. The scope is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for when cancellation is not allowed ('no changes after changeableUntil', 'no cancelling when canCancel is false') and points to the alternative ('reschedule instead'). It also differentiates the refund behavior before and after refundableUntil, giving the agent decision-relevant context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For event types with repeatMax (from get_public_profile): lists each meeting of a series that starts at start (one of the slots) and repeats every 1, 2 or 4 weeks at the same local time, and whether each is free. Book it with create_booking and repeat when bookable is true. A series is booked whole or not at all, and round robin gives every meeting to the same host.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit | |
| count | Yes | ||
| every | Yes | ||
| start | Yes | ||
| handle | Yes | 1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the basic safety profile is covered. The description adds valuable context beyond annotations: it reveals that series are booked whole or not at all, and that round robin assigns all meetings to the same host. This clarifies non-obvious behavioral implications of using the tool, and does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences—and front-loads the core purpose and key constraints. Every sentence adds value: the first states the action and inputs, the second connects to booking, and the third clarifies series semantics. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only checking tool with no output schema, the description is fairly complete. It explains the input context (repeatMax from get_public_profile), how to proceed after success (create_booking with repeat), and behavioral quirks (whole-series booking, round robin). The only gap is the undefined `count` parameter and lack of explicit error/edge-case handling, but given the tool's simplicity and annotation coverage, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (only handle and slug have any description). The description compensates for `start` (defines it as 'one of the slots') and `every` (explains it as 1, 2, or 4 weeks), but does not explain `count`, which is likely the number of meetings in the series. Since a required parameter is left ambiguous and the schema provides no description, the description only partially fulfills this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'lists each meeting of a series' with start time, frequency, and availability. It clearly names the resource (repeating series) and the output (whether each meeting is free), and distinguishes itself from generic slot listings by focusing on series behavior and connection to booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to check a series before booking) and directs the agent to create_booking with `repeat` when `bookable` is true. It also notes that a series must be booked whole and explains round-robin behavior. However, it does not explicitly enumerate alternatives or exclusions (e.g., when not to use this tool versus get_available_slots), so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Books start, which must be one of the slots from get_available_slots. Free events are confirmed at once. Paid events return status=pending_payment and a paymentUrl. Give it to the human to pay before holdExpiresAt, or the slot is released. Once confirmed, the event is added to the host's calendar if they connected one, and the invitee gets its invitation. Keep manageUrl and token: they are the only way to view, reschedule or cancel later. 409 slot_unavailable means the time was just taken: fetch slots again.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | the invitee's full name | |
| slug | Yes | 1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit | |
| Yes | |||
| notes | No | a string at most 2000 character(s) long | |
| start | Yes | ||
| handle | Yes | 1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit | |
| repeat | No | book a series instead: `count` meetings, `every` 1, 2 or 4 weeks at the same local time, when the event type's repeatMax allows. All or nothing: check_series first | |
| timezone | No | an IANA time zone such as "America/New_York" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/destructive annotations by disclosing side effects: free vs paid confirmation, hold expiry releasing the slot, host calendar insertion, invitee invitation delivery, and the importance of managing through manageUrl/token. It also exposes the 409 slot_unavailable behavior and recovery action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-organized: the booking rule comes first, then payment/hold behavior, then side effects, then management handles, then error handling. Every sentence adds operational value; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of paid/free booking, hold expiry, calendar side effects, and series options, the description covers all critical decision points an agent needs. The absence of an output schema makes the explicit mention of paymentUrl, status, holdExpiresAt, manageUrl, and token especially valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high at 75%, but the description adds essential meaning to `start` by requiring it to be one of the slots from get_available_slots. The repeat parameter is also enriched by the 'check_series first' and 'all or nothing' guidance, going beyond the raw schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with "Books `start`", naming a specific verb and resource, and immediately ties the booking to slots from get_available_slots. It clearly distinguishes creation from the later cancel/reschedule sibling operations by explicitly naming manageUrl and token as the means for those actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent to use a `start` value from get_available_slots, and the repeat field in the schema points to check_series first for series bookings. It does not explicitly say 'use this instead of X', but the workflow context and references to siblings give clear practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the start times that can be booked, with the hosts' calendars, buffers and limits already applied. Pass date (YYYY-MM-DD in timezone) or from and to (ISO, at most 62 days apart). With neither, it covers the next 7 days. days groups the slots by date in timezone (default UTC). For new times for an existing booking, also pass its bookingId and token. Next: call create_booking (or reschedule_booking_as_invitee) with one of the slots values as start.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| date | No | ||
| from | No | ||
| slug | Yes | 1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit | |
| token | No | a string at least 10 character(s) long | |
| handle | Yes | 1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit | |
| timezone | No | an IANA time zone such as "America/New_York" | |
| bookingId | No | a string at least 1 character(s) long |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate this is read-only and non-destructive, the description adds important behavioral context: availability already accounts for host calendars, buffers, and limits, date ranges are capped at 62 days, and timezone handling defaults to UTC. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, leading with the core behavior and then progressing through parameter modes and next steps. Every sentence adds useful guidance, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main input modes, defaults, timezone behavior, and how to use the returned slot values in subsequent booking calls. It is slightly incomplete on the exact meaning of handle and slug and does not fully define the output shape for slots beyond the mention of days grouping, but overall 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds real meaning to temporal parameters by specifying formats, allowed ranges, defaults, and timezone behavior, and it clarifies the special use of bookingId and token. However, the required handle and slug parameters are only syntactically described in the schema, so their semantic roles are left uncertain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns bookable start times with host calendars, buffers, and limits already applied. It also sets expectations for filtering and next steps, which distinguishes it from booking tools like create_booking and reschedule_booking_as_invitee.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains how to use date vs from/to ranges, the default 7-day window, and the need to pass bookingId and token for existing bookings. It also directs the agent to the next appropriate tool, create_booking or reschedule_booking_as_invitee, after obtaining slots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a booking by its id and token (from create_booking or its manageUrl), with changeableUntil, refundableUntil, canCancel and cancelReasonRequired. For a series, series lists every meeting with its own manageUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | a string at least 1 character(s) long | |
| token | Yes | a string at least 10 character(s) long |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the returned fields (changeableUntil, refundableUntil, canCancel, cancelReasonRequired) and the series behavior, which goes beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose and parameter source are front-loaded, and the series detail is appended without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with two required parameters and no output schema, the description covers what the tool returns, how the parameters are obtained, and the special series case. Nothing essential is missing for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only gives minLength constraints, so the description meaningfully explains that id and token come from create_booking or its manageUrl. This provenance is essential for the agent to know how to obtain valid parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('Returns a booking'), the resource ('by its id and token'), and the source of those values. It clearly distinguishes this read-only lookup from the mutating sibling tools like cancel_booking_as_invitee and reschedule_booking_as_invitee.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the prerequisite for using the tool: the id and token come from create_booking or its manageUrl. It implies the appropriate context is viewing an existing booking, but it does not explicitly compare against check_series or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Takes a handle, the first path segment of a booking link (https://host/acme/demo → "acme"). Returns the person or team and their bookable event types, with duration, price and hosts. A handle from before a rename also works. Next: call get_available_slots with one of the event type slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | 1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds genuine value beyond that: the behavioral note that a handle from before a rename still resolves, plus what the return payload contains. It stops short of covering error cases or rate limits, but for a read-only tool with annotations in place, the added context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: input definition with example, return value description, and the behavioral/workflow notes. It is front-loaded with the most important semantic information (the handle concept) and contains zero filler or restatement of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one fully documented parameter, the description covers the essential ground: input semantics, return contents, a backward-compatibility behavior, and the next workflow step. With no output schema, a slightly more explicit statement of the response shape or error handling for nonexistent handles would push it to 5, but the gaps are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the pattern and format of 'handle' are fully documented. The description adds the critical semantic layer the schema cannot: what a handle actually is in the domain (first path segment of a booking link) with a concrete example ('https://host/acme/demo' → 'acme'). This exceeds the baseline 3 by grounding the parameter in real-world usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title states a specific verb and resource ('List a person's or team's event types'), and the description reinforces it by naming the exact inputs (handle from a booking link) and outputs (person/team, event types with duration, price, hosts). It clearly differentiates from the sibling get_available_slots by positioning that tool as the follow-up step, making the boundary between the two obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to call it: when you have a handle, defined as the first path segment of a booking link, and it provides a clear next step ('call get_available_slots with one of the event type slugs'). It lacks explicit when-not-to-use conditions or an alternative-selection comparison against the other siblings, but the workflow guidance is strong enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requests access to host on Tempi (create event types, share a booking page). Not needed to book meetings, since booking pages are public. Returns the status: pending, approved (sign in at APP_URL/login), rejected, or open (no waitlist, sign in directly). Joining again with the same email returns the current status.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | a short source tag of lowercase letters, digits, - or _, like "embed" | |
| name | No | a string at most 100 character(s) long | |
| note | No | anything the admins should know, e.g. what you want to use Tempi for | |
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a mutating operation (readOnlyHint=false), and the description confirms it by requesting access. It adds valuable behavioral context: the idempotent behavior (joining again returns current status) and the possible return statuses (pending, approved, rejected, open). This goes beyond the basic annotation and helps the agent anticipate results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler. The core purpose is front-loaded, followed by a behavioral note and status explanations. Every sentence adds distinct value, and it remains compact despite covering multiple aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return values, and it does by listing the possible statuses and their meaning. It also covers the idempotency behavior. Given the tool's simplicity and the annotations, this is complete for an agent to invoke correctly; nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (three of four parameters have descriptions). The description adds semantics for the email parameter by stating that reusing the same email returns the current status, which clarifies its role as the key identifier. For other parameters (ref, name, note), the schema descriptions are sufficient, so the description does not need to elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Requests access to host') and the resource (Tempi hosting capability), and clarifies what it does not do (not needed for booking meetings because pages are public). This clearly distinguishes it from the sibling booking tools, which all deal with bookings and availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when the tool is not needed ('Not needed to book meetings'), giving a clear exclusion. It implies usage when the user wants to become a host, and the sibling list contains no other waitlist tool, so there is no ambiguity about alternatives. The guidance is clear but does not name an alternative tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves a confirmed booking to start with the same hosts. Get valid times from get_available_slots with this bookingId and token. The calendar event is updated and its provider notifies attendees. Payment carries over. Not possible after changeableUntil (409 change_too_late).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | a string at least 1 character(s) long | |
| start | Yes | ||
| token | Yes | a string at least 10 character(s) long |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite minimal annotations, the description discloses important side effects: the calendar event is updated, the provider notifies attendees, and payment carries over. It also documents a specific failure mode (409 change_too_late), going well beyond what the annotation flags provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences, each carrying a necessary fact: the core operation, the prerequisite workflow, and the side effects/constraints. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description covers prerequisites, side effects, carryover behavior, and the late-change failure condition. The agent has enough context to invoke the tool correctly and know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only gives generic length constraints and a date-time format, so the description adds meaning by identifying `id` as the booking identifier and `start` as a value sourced from get_available_slots. The `token` parameter's purpose is implied through the workflow reference but not explicitly explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Moves a confirmed booking to `start`'), the resource ('confirmed booking'), and key scope ('with the same hosts'). It also identifies the persona (invitee) and clearly distinguishes the operation from cancelling or creating a booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs the agent to get valid times from get_available_slots using the booking ID and token, and warns that rescheduling is not possible after `changeableUntil`. It does not explicitly contrast with cancel/rebook alternatives, but the prerequisites and blocking condition are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
join_waitlist1 field changedInput schema / properties / refAdded value: +{
+ "description": "a short source tag of lowercase letters, digits, - or _, like \"embed\"",
+ "pattern": "^[a-z0-9_-]{1,32}$",
+ "type": "string"
+}cancel_booking_as_inviteecheck_seriescreate_bookingget_available_slotsget_bookingget_public_profilejoin_waitlistreschedule_booking_as_inviteeAI-native scheduling and booking: check availability, book meetings, share links.
Group meeting scheduler — rank times everyone's free across Google & Outlook, book Meet/Teams.
Run your own Tempi scheduling account: event types, working hours, calendars and bookings.
Free no-signup group scheduling (a modern When2meet): share one link, find a time for everyone.
Add one secure layer between your agents and this server.