Find open times and book, reschedule or cancel meetings on anyone's Tempi link. No account needed.
Scored across 8 tools
Each tool has a clearly distinct resource and action: profile lookup, availability lookup, series checking, booking creation/retrieval, cancellation, rescheduling, and waitlist joining. The only potential overlap is check_series versus get_available_slots, but their descriptions clearly separate recurring-series validation from general slot listing.
All names use consistent snake_case with a verb-first pattern, such as get_public_profile, get_available_slots, create_booking, get_booking, cancel_booking_as_invitee, and reschedule_booking_as_invitee. The as_invitee suffix is applied consistently to invitee-side booking actions.
Eight tools is well-scoped for an invitee-focused booking server, covering discovery, availability, booking, retrieval, rescheduling, cancellation, recurring-series checks, and waitlist requests. No tool appears redundant or unnecessary for the stated workflow.
The set covers the core invitee lifecycle from finding a public profile and available slots through creating, retrieving, rescheduling, and cancelling bookings, including recurring-series and waitlist cases. Minor gaps remain, such as listing existing bookings without an id/token or checking payment status independently, but these are workable given manageUrl and token handling.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the booking id from create_booking, or its manageUrl | |
| token | Yes | the token from create_booking, or the manageUrl | |
| reason | No | why the invitee cancels, sent to the host | |
| following | No | for a series: also cancel every later meeting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: the event is removed from the host's calendar, refund rules keyed to refundableUntil, and the specific 409 error codes (change_too_late, cancel_not_allowed). This is rich behavioral disclosure that goes well past the structured hints.
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?
Core action and identity are front-loaded in the first sentence, then refund rules and gating conditions follow logically. Four dense sentences with no 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 destructive mutation with no output schema, the description covers side effects (calendar removal), refund outcomes, and the error conditions an agent must anticipate. Nothing needed to call it correctly 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 100%, so the schema already documents id, token, reason, and following. The description restates the id/token identification but adds no syntax or format detail for reason or following. Baseline 3 is appropriate when the schema carries the parameter burden.
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?
States a specific verb (cancels) and resource (booking) scoped to the invitee role, which cleanly distinguishes it from reschedule_booking_as_invitee and get_booking. An agent can identify the operation 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the conditions that block cancellation ('no cancelling when canCancel is false') and routes to the alternative ('reschedule instead'). It also tells the agent to consult get_booking for the event-type rules, giving both the when-not and the alternative.
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 host's clock time, and whether each is free. Pass the invitee's timezone to get each meeting's when in it: where clocks change on other dates than the host's, some meetings move for the invitee, and message says which. 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 | an event type slug from get_public_profile ("demo" in meettempi.com/acme/demo), or the whole link | |
| count | Yes | how many meetings, first included (2 up to the event type's repeatMax) | |
| every | Yes | weeks between meetings: 1, 2 or 4 | |
| start | Yes | one of the `slots` values from get_available_slots, as given (ISO in UTC) | |
| handle | Yes | a handle, the first part of a booking link ("acme" in meettempi.com/acme/demo), or the whole link | |
| timezone | No | the invitee's time zone, an IANA id like America/New_York or an abbreviation like EST: each meeting's `when` is in it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile, and the description adds substantial behavior beyond them: a series is atomic ('booked whole or not at all'), round robin pins all meetings to one host, and clocks changing on other dates can move some meetings for the invitee with `message` explaining which. This is exactly the extra context annotations cannot convey.
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?
Every sentence carries load: capability, timezone/DST semantics, booking hand-off, and atomicity/round-robin behavior. It is dense but front-loaded with the what, then the how, then the caveats, with no 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 6-parameter, read-only tool with no output schema, the description explains the returned concepts (`when`, `bookable`, `message`) and the constraints an agent needs before calling, including the atomic-booking and round-robin consequences.
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 schema already documents all six parameters (baseline 3). The description still adds real meaning: `every` repeats 'at the host's clock time', `start` must be one of the slots, `timezone` shifts each meeting's `when` and can move it on DST dates, and `count` is bounded by the event type's repeatMax.
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?
States a specific verb (lists/checks) and resource (each meeting of a repeating series), plus the exact scope: starts at `start`, repeats `every` 1/2/4 weeks, reports free/busy per meeting. An agent can distinguish this from get_available_slots and create_booking without opening a schema.
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?
Gives the precondition ('For event types with `repeatMax` from get_public_profile'), the follow-up action and its condition ('Book it with create_booking and `repeat` when `bookable` is true'), and implicitly routes non-repeating cases elsewhere. Alternatives are named explicitly.
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, unless the event type has requiresApproval: then it's a request (status=pending_approval) that holds the time until a host approves or declines it, and the invitee hears either way by email. Nobody answering by its start (holdExpiresAt) lets it lapse. Tell the human it isn't confirmed yet. 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 a confirmation email with a calendar file (.ics). Keep manageUrl and token: they are the only way to view, reschedule or cancel later. 409 slot_unavailable says why the time can't be booked and lists the nearest open times. The result's when is the start in the invitee's time zone, to tell them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | the invitee's full name | |
| slug | Yes | an event type slug from get_public_profile ("demo" in meettempi.com/acme/demo), or the whole link | |
| cover | No | leave it out: the id of the painting the booking page showed, when the event type shows a different one each booking (cover "hand", "light" or "still"), so the booking keeps it. Anything else is ignored, and Tempi picks one | |
| Yes | the invitee's email address, which gets the confirmation and its calendar file | ||
| notes | No | anything the invitee wants the host to know | |
| phone | No | the invitee's phone number with its country code, like +1 415 555 0134: required when the event type is a phone call (whereKind phone on get_public_profile), where the host calls them | |
| start | Yes | one of the `slots` values from get_available_slots, as given (ISO in UTC) | |
| handle | Yes | a handle, the first part of a booking link ("acme" in meettempi.com/acme/demo), or the whole link | |
| repeat | No | book a series instead: `count` meetings, `every` 1, 2 or 4 weeks at the host's clock time, when the event type's repeatMax allows. All or nothing: check_series first. The result's `series.meetings` give each start as `when` in the invitee's time zone, and `series.clockNote` says when that moves | |
| timezone | Yes | the invitee's time zone, an IANA id like America/New_York or an abbreviation like EST: their emails and reminders show times in it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly=false, destructive=false, openWorld=false; the description carries the real behavior burden and discloses it richly: pending_approval holds, holdExpiresAt lapse, pending_payment + paymentUrl, slot release on non-payment, host-calendar insertion, confirmation email with .ics, and the 409 slot_unavailable error with `nearest` alternatives. This is far beyond what annotations 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?
Front-loaded with the core action and the slot constraint, then ordered by outcome (free → approval → paid → confirmed → error). The single dense paragraph wastes almost nothing, though the output/return-value detail (manageUrl, token, series.meetings, `when`) makes it long and would read better split into labeled sentences against the missing output schema.
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?
No output schema exists, and the description compensates fully: it names the returned statuses, paymentUrl, manageUrl/token (and warns they are the only way to manage later), `when` in the invitee's time zone, series.meetings/clockNote, and the 409 nearest list. Combined with 10 parameters and a nested `repeat` object, an agent has everything needed to invoke this 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% and the schema already documents `start`, `timezone`, `slug`, `handle`, `phone`, `repeat` in detail, so the baseline is 3. The description reinforces rather than adds: it repeats that `start` must be one of the get_available_slots values and that `timezone` drives email display, both of which the schema already states. No new syntax or format guidance beyond the structured fields.
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?
Opens with a specific verb+resource ("Books `start`") and immediately pins the value to a source (slots from get_available_slots), which is exactly the ambiguity for a booking tool. It is clearly distinguishable from its siblings (cancel/reschedule_as_invitee, check_series), several of which it names or implicitly routes to.
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 routes the agent explicitly: `start` must come from get_available_slots, and series bookings must go through check_series first ("All or nothing: check_series first"). It also gives the branch conditions (requiresApproval, paid events). It stops short of an explicit "do not use this when…" rule or a named alternative for one-off vs series beyond check_series.
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 the invitee's timezone and either 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, and times gives each slot as a local time to show people. People can book up to bookableUntil. When the range has no open times, next is the next one. When timezone was an abbreviation that names more than one zone (CST, IST, BST), timezoneNote says which one was used: check it with the person. 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 | end of the range, ISO with an offset | |
| date | No | one day to look at, as YYYY-MM-DD in `timezone` | |
| from | No | start of the range, ISO with an offset | |
| slug | Yes | an event type slug from get_public_profile ("demo" in meettempi.com/acme/demo), or the whole link | |
| token | No | the token from create_booking, or the manageUrl | |
| handle | Yes | a handle, the first part of a booking link ("acme" in meettempi.com/acme/demo), or the whole link | |
| timezone | Yes | the invitee's time zone, an IANA id like America/New_York or an abbreviation like EST: days, dates and times are in it | |
| bookingId | No | the booking id from create_booking, or its manageUrl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), yet the description adds substantial behavior: the 62-day max range, the 7-day default window, ambiguity handling for zone abbreviations via `timezoneNote`, and the `next` fallback when nothing is open. These are constraints and edge cases an agent cannot infer from the read-only 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 purpose is front-loaded in the first sentence and the remaining sentences each carry distinct, load-bearing information (range rules, defaults, abbreviation caveat, next-step routing). It is dense and slightly long, but there is no filler or repetition.
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?
With no output schema, the description carries the full burden of describing return values and does so: `days`, `times`, `bookableUntil`, `next`, `timezoneNote`, and `slots`. Combined with the range defaults, abbreviation caveat and the explicit next-step call, an agent has everything needed to invoke it 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, but the description adds real semantics beyond the schema: it explains that `date`/`from`/`to` are mutually exclusive modes, that the range is capped at 62 days, and that `timezone` governs the interpretation of days, dates and times. It also clarifies `days`/`times` grouping behavior that the schema does not describe.
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?
States a specific verb and resource ('Returns the start times that can be booked') and immediately qualifies scope ('with the hosts' calendars, buffers and limits already applied'). It also routes clearly away from siblings by naming create_booking and reschedule_booking_as_invitee as the follow-up tools, so an agent can place it in the workflow without opening a schema.
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?
Gives concrete context for use: pass `date` or `from`/`to`, defaults to the next 7 days when neither is given, and pass `bookingId`/`token` when looking for new times on an existing booking. It stops short of explicitly stating when NOT to use it versus get_booking or get_public_profile, but the conditions that select each parameter mode are spelled out.
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 passed as both, with changeableUntil, refundableUntil and canCancel. For a series, series lists every meeting with its own manageUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the booking id from create_booking, or its manageUrl | |
| token | Yes | the token from create_booking, or the manageUrl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower, yet the description still adds real behavior: the returned policy fields changeableUntil, refundableUntil, canCancel, and the fact that a series response expands into per-meeting manageUrls. It omits failure behavior for an invalid token/id, which keeps it out of 5 territory.
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 sentences, front-loaded with the core action, with no filler. The first sentence is heavily parenthetical and slightly dense, but every clause (identifier forms, three policy fields, series expansion) carries information an agent needs.
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?
With no output schema, the description partially compensates by naming the key return fields and the series shape, and annotations cover the safety profile. It is complete enough to call correctly, though a note on invalid-credential behavior or output shape beyond the named fields would close the remaining gap.
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 100% and both property descriptions already state "the booking id from create_booking, or its manageUrl", so the description largely restates what the schema provides. The dual-use manageUrl-as-both-arguments trick is clarified slightly, but not enough to exceed the baseline.
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 gives a specific verb and resource ("Returns a booking by its id and token"), then names the two accepted identifier forms, which is exactly the ambiguity an agent would otherwise stumble on. It also covers the series case, which is the one behavior that could be confused with the sibling check_series, so the agent can tell the tools apart without opening a schema.
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 explains where the inputs come from ("from create_booking", or the manageUrl passed as both), which is genuine invocation guidance. However, it never states when to call this versus check_series or the reschedule/cancel siblings, so the when-to-use decision is only implied by the resource name.
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"), or the link itself. Returns the person or team and their bookable event types, with duration, price, and hosts with their time zones (hostTimezones, so you can say what time a slot is for them). 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 | a handle, the first part of a booking link ("acme" in meettempi.com/acme/demo), or the whole link |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, non-destructive, closed-world read, so safety needs no restating. The description adds genuinely useful behavior beyond that: the return shape (event types with duration, price, hosts, and hostTimezones for time-zone framing) and the edge case that handles from before a rename still resolve.
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 tight sentences: handle format first, then what is returned, then the next call. No filler, and the most load-bearing information (input format and return contents) is front-loaded.
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 carries the burden of describing the response — and it does, covering the profile, event types, duration, price, hosts, and time zones. With one fully documented parameter and annotations covering the safety profile, nothing needed to invoke or interpret this tool 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 coverage is 100% and the schema already documents the handle format with its own URL example, so the description largely repeats it. It adds mild clarity by naming the first path segment explicitly, but not meaningfully beyond the structured field — the baseline 3 applies.
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?
States a specific action and resource: resolves a handle and returns the person/team plus their bookable event types with duration, price, and hosts. This is clearly distinguishable from siblings like get_booking (a single reservation) or get_available_slots (time slots), and the entry-point role in the booking flow is explicit.
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?
Explicitly routes the agent forward: 'Next: call get_available_slots with one of the event type slugs.' That establishes the workflow context well, but it gives no when-not-to-use guidance or exclusions versus other lookup tools, so it stops short of the top score.
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 to the Tempi web app), 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 | the person’s name (at most 100 characters) | |
| note | No | anything the admins should know, e.g. what you want to use Tempi for | |
| Yes | an email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, non-destructive operation, so the write nature is covered; the description goes further by enumerating the four possible return statuses and what each implies for the user (approved → sign in, open → no waitlist) and by declaring idempotency on repeat email. With no output schema, this return-value detail is the valuable addition. It does not mention rate limits, admin approval timing, or whether submissions are ever purged.
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?
Four sentences, all load-bearing, with the core purpose front-loaded before the exclusion and the return-status list. Slightly dense due to nested parentheticals ('(create event types, share a booking page)', '(no waitlist, sign in directly)'), which cost a little readability.
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 small 4-parameter mutation with no output schema, the description covers purpose, exclusion case, return statuses, and repeat-call semantics. What remains unaddressed is minimal: no auth/permission prerequisites are stated for the submitter, and approval timing is left to the admin flow.
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 100%, so ref, name, note, and email are all self-documented with patterns and length limits. The description adds only the implicit notion that email identifies the caller for idempotent re-joins, which is marginal beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb and resource — requesting host access on Tempi — and immediately scopes it with examples of what that enables (event types, booking page). It also draws a clear line against the booking-oriented siblings: 'Not needed to book meetings, since booking pages are public.' An agent can separate this from create_booking/get_available_slots without opening a schema.
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?
Gives an explicit when (you want to host), an explicit when-not (you only want to book a meeting, which is public and needs no waitlist), and follow-up behavior for repeat calls ('Joining again with the same email returns the current status'). The main confusion case — using this instead of just booking — is pre-empted.
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). A request (status=pending_approval) can’t be moved: cancel it and request another time.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the booking id from create_booking, or its manageUrl | |
| start | Yes | one of the `slots` values from get_available_slots, as given (ISO in UTC) | |
| token | Yes | the token from create_booking, or the manageUrl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: calendar event update, provider attendee notification, payment carry-over, 409 change_too_late error, and the prohibition on moving pending_approval requests. Annotations only confirm it is a non-destructive write.
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?
Five sentences, each carrying a different constraint or behavior. Front-loaded with the core action and well-structured, though slightly dense with edge cases.
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?
Covers preconditions, side effects, error condition, and the pending_approval exclusion. No output schema exists, but the return is implied by success behavior; minor gap on whether the response returns updated booking details.
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 value by telling where valid `start` values come from (get_available_slots) and that both `bookingId` and `token` are required to fetch them, which complements the schema's formatting detail.
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?
States a specific verb (moves) and resource (confirmed booking to `start`) with the scope constraint (same hosts). Distinguishes from siblings by implying cancel_booking_as_invitee is the alternative for non-movable requests.
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?
Explicitly names get_available_slots as the source of valid times, describes the precondition (before changeableUntil), and gives an alternative workflow for pending_approval requests: cancel and re-request. This routes the agent without ambiguity.
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.
create_booking1 field changedInput schema / properties / email / descriptionPrevious value: -"the invitee's email address, which gets the calendar invitation"New value: +"the invitee's email address, which gets the confirmation and its calendar file"create_booking1 field changedInput schema / properties / phoneAdded value: +{
+ "description": "the invitee's phone number with its country code, like +1 415 555 0134: required when the event type is a phone call (whereKind phone on get_public_profile), where the host calls them",
+ "maxLength": 40,
+ "minLength": 0,
+ "title": "maxLength(40)",
+ "type": "string"
+}create_booking1 field changedInput schema / properties / coverAdded value: +{
+ "description": "leave it out: the id of the painting the booking page showed, when the event type shows a different one each booking (cover \"hand\", \"light\" or \"still\"), so the booking keeps it. Anything else is ignored, and Tempi picks one",
+ "maxLength": 40,
+ "title": "maxLength(40)",
+ "type": "string"
+}check_series3 fields changedInput schema / properties / count / descriptionAdded value: +"how many meetings, first included (2 up to the event type's repeatMax)"Input schema / properties / every / descriptionAdded value: +"weeks between meetings: 1, 2 or 4"Input schema / properties / timezoneAdded value: +{
+ "description": "the invitee's time zone, an IANA id like America/New_York or an abbreviation like EST: each meeting's `when` is in it",
+ "type": "string"
+}create_booking1 field changedInput schema / properties / repeat / descriptionPrevious value: -"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"New value: +"book a series instead: `count` meetings, `every` 1, 2 or 4 weeks at the host's clock time, when the event type's repeatMax allows. All or nothing: check_series first. The result's `series.meetings` give each start as `when` in the invitee's time zone, and `series.clockNote` says when that moves"join_waitlist2 fields changedInput schema / properties / name / descriptionPrevious value: -"a string at most 100 character(s) long"New value: +"the person’s name (at most 100 characters)"Input schema / properties / note / descriptionPrevious value: -"a string at most 1000 character(s) long"New value: +"anything the admins should know, e.g. what you want to use Tempi for"cancel_booking_as_invitee7 fields changedInput schema / properties / id / descriptionPrevious value: -"a string at least 1 character(s) long"New value: +"the booking id from create_booking, or its manageUrl"Input schema / properties / id / minLengthRemoved value: -1Input schema / properties / id / titleRemoved value: -"minLength(1)"Input schema / properties / reason / descriptionPrevious value: -"a string at most 500 character(s) long"New value: +"why the invitee cancels, sent to the host"Input schema / properties / token / descriptionPrevious value: -"a string at least 10 character(s) long"New value: +"the token from create_booking, or the manageUrl"Input schema / properties / token / minLengthRemoved value: -10Input schema / properties / token / titleRemoved value: -"minLength(10)"check_series10 fields changedInput schema / $defsRemoved value: -{
- "NumberFromString": {
- "description": "a string to be decoded into a number",
- "type": "string"
- }
-}Input schema / properties / count / $refRemoved value: -"#/$defs/NumberFromString"Input schema / properties / count / anyOfAdded value: +[
+ {
+ "description": "how many meetings, first included (2 up to the event type's repeatMax)",
+ "maximum": 52,
+ "minimum": 2,
+ "title": "between(2, 52)",
+ "type": "integer"
+ },
+ {
+ "description": "a string to be decoded into a number",
+ "type": "string"
+ }
+]Input schema / properties / every / $refRemoved value: -"#/$defs/NumberFromString"Input schema / properties / every / anyOfAdded value: +[
+ {
+ "description": "weeks between meetings: 1, 2 or 4",
+ "enum": [
+ 1,
+ 2,
+ 4
+ ],
+ "type": "number"
+ },
+ {
+ "description": "a string to be decoded into a number",
+ "type": "string"
+ }
+]Input schema / properties / handle / descriptionPrevious value: -"1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit"New value: +"a handle, the first part of a booking link (\"acme\" in meettempi.com/acme/demo), or the whole link"Input schema / properties / handle / patternRemoved value: -"^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$"Input schema / properties / slug / descriptionPrevious value: -"1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit"New value: +"an event type slug from get_public_profile (\"demo\" in meettempi.com/acme/demo), or the whole link"Input schema / properties / slug / patternRemoved value: -"^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$"Input schema / properties / start / descriptionAdded value: +"one of the `slots` values from get_available_slots, as given (ISO in UTC)"create_booking13 fields changedInput schema / $defsRemoved value: -{
- "Trim": {
- "description": "a string that will be trimmed",
- "type": "string"
- }
-}Input schema / properties / email / descriptionAdded value: +"the invitee's email address, which gets the calendar invitation"Input schema / properties / handle / descriptionPrevious value: -"1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit"New value: +"a handle, the first part of a booking link (\"acme\" in meettempi.com/acme/demo), or the whole link"Input schema / properties / handle / patternRemoved value: -"^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$"Input schema / properties / name / $refRemoved value: -"#/$defs/Trim"Input schema / properties / name / descriptionAdded value: +"the invitee's full name"Input schema / properties / name / typeAdded value: +"string"Input schema / properties / notes / descriptionPrevious value: -"a string at most 2000 character(s) long"New value: +"anything the invitee wants the host to know"Input schema / properties / slug / descriptionPrevious value: -"1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit"New value: +"an event type slug from get_public_profile (\"demo\" in meettempi.com/acme/demo), or the whole link"Input schema / properties / slug / patternRemoved value: -"^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$"Input schema / properties / start / descriptionAdded value: +"one of the `slots` values from get_available_slots, as given (ISO in UTC)"Input schema / properties / timezone / descriptionPrevious value: -"an IANA time zone such as \"America/New_York\""New value: +"the invitee's time zone, an IANA id like America/New_York or an abbreviation like EST: their emails and reminders show times in it"Input schema / requiredPrevious value: -[
- "handle",
- "slug",
- "start",
- "name",
- "email"
-]New value: +[
+ "handle",
+ "slug",
+ "start",
+ "name",
+ "email",
+ "timezone"
+]get_available_slots15 fields changedInput schema / properties / bookingId / descriptionPrevious value: -"a string at least 1 character(s) long"New value: +"the booking id from create_booking, or its manageUrl"Input schema / properties / bookingId / minLengthRemoved value: -1Input schema / properties / bookingId / titleRemoved value: -"minLength(1)"Input schema / properties / date / descriptionAdded value: +"one day to look at, as YYYY-MM-DD in `timezone`"Input schema / properties / from / descriptionAdded value: +"start of the range, ISO with an offset"Input schema / properties / handle / descriptionPrevious value: -"1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit"New value: +"a handle, the first part of a booking link (\"acme\" in meettempi.com/acme/demo), or the whole link"Input schema / properties / handle / patternRemoved value: -"^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$"Input schema / properties / slug / descriptionPrevious value: -"1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit"New value: +"an event type slug from get_public_profile (\"demo\" in meettempi.com/acme/demo), or the whole link"Input schema / properties / slug / patternRemoved value: -"^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$"Input schema / properties / timezone / descriptionPrevious value: -"an IANA time zone such as \"America/New_York\""New value: +"the invitee's time zone, an IANA id like America/New_York or an abbreviation like EST: days, dates and times are in it"Input schema / properties / to / descriptionAdded value: +"end of the range, ISO with an offset"Input schema / properties / token / descriptionPrevious value: -"a string at least 10 character(s) long"New value: +"the token from create_booking, or the manageUrl"Input schema / properties / token / minLengthRemoved value: -10Input schema / properties / token / titleRemoved value: -"minLength(10)"Input schema / requiredPrevious value: -[
- "handle",
- "slug"
-]New value: +[
+ "handle",
+ "slug",
+ "timezone"
+]get_booking6 fields changedInput schema / properties / id / descriptionPrevious value: -"a string at least 1 character(s) long"New value: +"the booking id from create_booking, or its manageUrl"Input schema / properties / id / minLengthRemoved value: -1Input schema / properties / id / titleRemoved value: -"minLength(1)"Input schema / properties / token / descriptionPrevious value: -"a string at least 10 character(s) long"New value: +"the token from create_booking, or the manageUrl"Input schema / properties / token / minLengthRemoved value: -10Input schema / properties / token / titleRemoved value: -"minLength(10)"get_public_profile2 fields changedInput schema / properties / handle / descriptionPrevious value: -"1-40 lowercase letters, digits or dashes, starting and ending with a letter or digit"New value: +"a handle, the first part of a booking link (\"acme\" in meettempi.com/acme/demo), or the whole link"Input schema / properties / handle / patternRemoved value: -"^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$"join_waitlist2 fields changedInput schema / properties / email / descriptionAdded value: +"an email address"Input schema / properties / note / descriptionPrevious value: -"anything the admins should know, e.g. what you want to use Tempi for"New value: +"a string at most 1000 character(s) long"reschedule_booking_as_invitee7 fields changedInput schema / properties / id / descriptionPrevious value: -"a string at least 1 character(s) long"New value: +"the booking id from create_booking, or its manageUrl"Input schema / properties / id / minLengthRemoved value: -1Input schema / properties / id / titleRemoved value: -"minLength(1)"Input schema / properties / start / descriptionAdded value: +"one of the `slots` values from get_available_slots, as given (ISO in UTC)"Input schema / properties / token / descriptionPrevious value: -"a string at least 10 character(s) long"New value: +"the token from create_booking, or the manageUrl"Input schema / properties / token / minLengthRemoved value: -10Input schema / properties / token / titleRemoved value: -"minLength(10)"create_booking3 fields changedInput schema / properties / name / $refAdded value: +"#/$defs/Trim"Input schema / properties / name / allOfRemoved value: -[
- {
- "$ref": "#/$defs/Trim"
- }
-]Input schema / properties / name / descriptionRemoved value: -"the invitee's full name"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_inviteeCheck availability, book meetings and find group times — without sharing your calendar.
AI-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.
Add one secure layer between your agents and this server.