Book meetings on a host's real availability. No auth - mirrors their public Yoya page.
Scored across 7 tools
Each tool targets a distinct action: availability lookup, preview, booking, retrieval, rescheduling, cancellation, and public page info. Even closely related tools like preview_booking and book_meeting are clearly separated by validation versus creation.
Tool names consistently follow a verb_noun snake_case pattern such as list_available_times, preview_booking, and cancel_booking. Minor variation like book_meeting versus booking_* still reads predictably.
Seven tools provide a focused surface for a booking service without redundancy. Each tool is necessary for the browse-preview-book-manage workflow.
The set covers the full booking lifecycle: discover availability, preview, create, read, reschedule, and cancel, plus public page info. Payment-related status is exposed through get_booking's sync status, so there are no obvious dead ends.
Creates a free booking or returns PAYMENT_REQUIRED with a secure payment URL for paid meetings. Paid meetings are not booked until payment succeeds; show the link and never claim confirmation before that. Only call after the guest explicitly approves preview_booking. Copy the preview's booking fields and confirmationToken unchanged. Reuse requestId and token on network retries; never claim notifications are delivered until syncStatus is ready.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| slug | Yes | ||
| Yes | |||
| slotId | Yes | ||
| purpose | No | ||
| timezone | No | ||
| confirmed | Yes | ||
| requestId | No | Reuse the ID returned by preview_booking for retries. | |
| meetingType | No | ||
| fieldAnswers | No | ||
| meetingFormat | No | Copy the value from preview_booking unchanged. | |
| confirmationToken | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | No | |
| message | No | |
| nextCursor | No | |
| nextOffset | No | |
| syncStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical runtime behavior: paid meetings are not booked until payment succeeds, the secure payment URL must be shown without claiming confirmation, and notifications must not be considered delivered until syncStatus is ready. This adds substantial value beyond readOnly/destructive 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?
Four dense sentences, all earning their place: outcome, payment caveat, precondition, and retry/notification constraints. The most important usage rule is front-loaded, and 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 12-parameter tool with an output schema, the description covers the essential operational context: when to call, what to copy, how to handle paid bookings, retries, and sync status. The output schema handles return-value specifics, so nothing needed for correct invocation is materially 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 very low (17%), but the description compensates with crucial guidance: copy the preview's booking fields and confirmationToken unchanged, and reuse requestId and confirmationToken on retries. It does not individually explain every parameter, but the copy-unmodified instruction covers most booking fields and targets the highest-risk semantics.
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 and resource: it creates a free booking or returns PAYMENT_REQUIRED for paid ones. It clearly distinguishes itself from siblings by tying directly to preview_booking approval, so an agent can tell book_meeting apart from preview, reschedule, and cancel.
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 an explicit precondition: only call after the guest explicitly approves preview_booking. It also clarifies the paid-meeting flow, retry behavior, and when not to claim confirmation or notification delivery, leaving little room for misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel using a private manage token. Ask the guest for explicit approval first; this sends cancellation notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| reason | No | ||
| confirmed | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | No | |
| message | No | |
| nextCursor | No | |
| nextOffset | No | |
| syncStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: authentication via a private manage token, that explicit guest approval is required, and that cancellation notifications are sent as a side effect. That side-effect disclosure is exactly the kind of behavioral detail 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?
Two short sentences with zero filler, front-loaded with the action and authentication mode. Every clause earns its place, including the approval warning and notification side effect.
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?
An output schema exists, so return values need no explanation, and the annotations carry the safety profile. What remains missing is only the reason parameter's semantics — minor against an otherwise complete picture of a mutation tool.
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 0%, so the description must compensate for three undocumented parameters. It does add meaning for two: 'private manage token' clarifies the token semantics and 'ask the guest for explicit approval' explains the confirmed flag's intent. The reason parameter is left entirely unexplained in both schema and description.
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 (cancel) and resource (booking), plus the auth mechanism (private manage token) that separates it from read-side siblings like get_booking. It does not explicitly name reschedule_booking as the alternative, so it stops short of full sibling differentiation.
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 one real precondition — ask the guest for explicit approval first — which is genuinely useful routing advice. However, it never says when to cancel versus reschedule_booking, nor any when-not condition, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a booking using its private manage-link token. Includes meeting-link synchronization status. Treat this token as a password; do not share it publicly.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | No | |
| message | No | |
| nextCursor | No | |
| nextOffset | No | |
| syncStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds meaningful context beyond that: the token acts as a credential ('treat as a password, do not share publicly') and that the response includes meeting-link sync status. This is useful behavioral disclosure the annotations don't 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?
Three short sentences, front-loaded with what the tool does, then the return content, then the security caveat. No wasted text.
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?
An output schema exists so return values needn't be detailed; the description notes one return aspect (meeting-link sync status) and covers the security-relevant behavior of the token. Minor gap: no explicit when-to-use guidance, but the tool is simple enough that this is acceptable.
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 0% for the one required parameter, but the description compensates by explaining the token's meaning and sensitivity (a password-like manage link). The regex format (64 hex chars) is only in the schema. Baseline 3 is appropriate given the description partially covers the single param.
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 (read) and resource (booking) with the scoping mechanism (private manage-link token). Distinguishes from siblings like get_booking_page or list_available_times by being the token-based single-booking fetch.
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?
Implies the retrieval context via 'using its private manage-link token' but never states when to use this vs. get_booking_page or preview_booking, nor any prerequisites. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a public Yoya booking link or slug. Includes required guest fields and meeting options. No host account access.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | No | |
| message | No | |
| nextCursor | No | |
| nextOffset | No | |
| syncStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and non-open-world. The description adds value beyond them by disclosing the auth posture ('no host account access') and what the page content contains (guest fields and meeting options). Return shape is covered by the output schema, so this is adequate.
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 declarative sentences, no filler, with the core action front-loaded. Every sentence (what it reads, what it returns, what auth it needs) earns its place.
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 single-parameter read tool with a full annotation set and an output schema, the description covers purpose, auth requirements, and content scope. It is nearly complete; only the explicit sibling-disambiguation 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 0% for the single 'slug' parameter, but the description clarifies that it accepts 'a public Yoya booking link or slug' — meaning a full URL may also be accepted, which is non-obvious from the schema. With only one parameter and an output schema present, this is a modest but real contribution.
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 ('Read') and resource ('public Yoya booking link or slug'), and the word 'public' helps separate it from siblings like get_booking and preview_booking. It stops short of explicitly naming the sibling it contrasts with, so it is clear but not maximally differentiated.
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?
'No host account access' signals the caller does not need to be authenticated as a host, which is implicit guidance on when this applies. However, it never contrasts the use case against get_booking, preview_booking, or book_meeting, leaving the agent to infer which sibling to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find up to 10 times (max 50), labeled in the guest's IANA timezone. Filter by inclusive from/exclusive to datetimes and morning (06–12), afternoon (12–18) or evening (18–24) in the guest timezone. Pass nextCursor unchanged to continue with the same filters. Slots are suggestions; preview then book rechecks availability. Never invent slot IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| slug | Yes | ||
| limit | No | ||
| cursor | No | ||
| timezone | No | ||
| timeOfDay | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | No | |
| message | No | |
| nextCursor | No | |
| nextOffset | No | |
| syncStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive profile, so safety is covered. The description adds real behavioral context beyond that: the 50-slot cap, cursor continuation semantics ('same filters'), the caveat that slots are advisory, and the explicit 'Never invent slot IDs' guardrail.
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 dense sentences, front-loaded with the core action and constraints, with no filler. Each sentence carries a distinct constraint (cap, filters, pagination, correctness guardrail).
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 paginated, timezone-sensitive query tool with 7 params, 0% schema coverage and an existing output schema, the description covers nearly everything an agent needs to call it correctly. The only gap is the undocumented slug param and the cursor/nextCursor naming inconsistency.
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 0%, so the description carries the burden and mostly delivers: it explains limit bounds (10/max 50), inclusive from / exclusive to, the morning/afternoon/evening split with hour ranges, and timezone labeling. It leaves slug unexplained and names the cursor parameter 'nextCursor' while the schema calls it 'cursor', a minor mismatch.
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 ('Find up to 10 times') with concrete scope and output characteristics. An agent can distinguish this listing/queries tool from the booking siblings (preview_booking, book_meeting) 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?
The line 'Slots are suggestions; preview then book rechecks availability' implicitly routes the agent to preview_booking then book_meeting after listing. Clear usage context, but it does not explicitly name those alternatives 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.
Validate guest details and the selected time without booking or sending email. Show the returned summary to the guest and ask for explicit approval. Then call book_meeting with the returned normalized booking, requestId and confirmationToken.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| slug | Yes | ||
| Yes | |||
| slotId | Yes | ||
| purpose | No | ||
| timezone | No | ||
| requestId | No | Reuse the ID returned by preview_booking for retries. | |
| meetingType | No | ||
| fieldAnswers | No | ||
| meetingFormat | No | Copy the value from preview_booking unchanged. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | No | |
| message | No | |
| nextCursor | No | |
| nextOffset | No | |
| syncStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It states the tool performs no booking and sends no email, matching the readOnly/idempotent annotations without contradiction. It additionally discloses the required human-approval step and the handoff of normalized booking, requestId, and confirmationToken to the next call, which annotations do not 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?
Three short sentences front-load the purpose, add the non-side-effect qualifier, and give the exact follow-up call. There is no redundant or filler content.
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 workflow, output handoff, and safety profile are complete, and the presence of an output schema covers return-value details. The main gap is input parameter semantics for the many non-obvious fields, but the required fields are named and the purpose is clear enough for 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?
Schema description coverage is only 20%, so the prose needed to compensate, but it only maps vaguely to 'guest details' and 'selected time.' It does not explain slug, slotId, purpose, timezone, meetingType, or fieldAnswers, leaving most required parameters underdocumented; only requestId and meetingFormat are clarified in the schema.
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 names a specific action—validate guest details and selected time—and explicitly scopes it as 'without booking or sending email.' It also distinguishes preview_booking from the finalization sibling by prescribing book_meeting as the follow-up.
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 defines the correct workflow: preview first, show the summary to the guest, get explicit approval, and only then call book_meeting with the returned tokens. This clearly positions the tool as a pre-confirmation validation step relative to its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a booking using its private manage token and a fresh slot ID from list_available_times. Ask for explicit approval first. The original booking stays intact if the new time cannot be reserved.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| reason | No | ||
| slotId | Yes | ||
| confirmed | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| code | No | |
| message | No | |
| nextCursor | No | |
| nextOffset | No | |
| syncStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: the operation is atomic/all-or-nothing ('the original booking stays intact if the new time cannot be reserved') and requires an approval gate. It does not discuss failure modes beyond that or rate limits, so it is not exhaustive.
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, no filler, with the core action stated first, the prerequisite source second, and the safety guarantee last. Every sentence adds information.
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, non-idempotent mutation, the description covers the approval requirement, token-based authorization, and rollback semantics; return values need no explanation because an output schema exists. The only residual gap is that 'reason' and 'confirmed' remain unexplained at 0% schema coverage.
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 0% across 4 parameters, so the description must carry the load. It does explain 'token' (private manage token) and 'slotId' (a fresh slot from list_available_times), but 'reason' and 'confirmed' are never addressed directly — approval is implied before confirmation, but the required confirmed=true flag is left to the schema's const.
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?
Precise verb+resource ('Move a booking'), and it identifies the two key inputs as its basis: the private manage token and a slot ID sourced from list_available_times. An agent can distinguish this from cancel_booking or preview_booking without opening any 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 routes the agent to list_available_times as the source of valid slot IDs and mandates 'Ask for explicit approval first', which is real workflow guidance. It stops short of naming when to prefer preview_booking or other siblings, so it is clear context without full when/when-not coverage.
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.
book_meeting1 field changedInput schema / properties / meetingFormatAdded value: +{
+ "description": "Copy the value from preview_booking unchanged.",
+ "maxLength": 1000,
+ "type": "string"
+}preview_booking1 field changedInput schema / properties / meetingFormatAdded value: +{
+ "description": "Copy the value from preview_booking unchanged.",
+ "maxLength": 1000,
+ "type": "string"
+}book_meeting21 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / confirmationTokenAdded value: +{
+ "maxLength": 1000,
+ "type": "string"
+}Input schema / properties / confirmedAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Input schema / properties / email / maxLengthAdded value: +320Input schema / properties / email / minLengthRemoved value: -1Input schema / properties / fieldAnswers / additionalProperties / maxLengthAdded value: +2000Input schema / properties / fieldAnswers / descriptionRemoved value: -"Answers to the page's requiredFields, keyed by label."Input schema / properties / fieldAnswers / propertyNames / maxLengthAdded value: +60Input schema / properties / fieldAnswers / propertyNames / minLengthAdded value: +1Input schema / properties / meetingType / descriptionRemoved value: -"Required when the page offers more than one option."Input schema / properties / name / maxLengthAdded value: +200Input schema / properties / purpose / descriptionRemoved value: -"One line on why the guest wants to meet."Input schema / properties / purpose / maxLengthAdded value: +2000Input schema / properties / requestId / descriptionPrevious value: -"Reuse this ID when retrying the same confirmed booking request."New value: +"Reuse the ID returned by preview_booking for retries."Input schema / properties / slotId / minLengthRemoved value: -1Input schema / properties / slotId / patternAdded value: +"^s_\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}Z$"Input schema / properties / slug / maxLengthAdded value: +2048Input schema / properties / timezone / descriptionRemoved value: -"Guest IANA timezone; defaults to the host's."Input schema / properties / timezone / maxLengthAdded value: +100Input schema / requiredPrevious value: -[
- "slug",
- "name",
- "email",
- "slotId"
-]New value: +[
+ "slug",
+ "name",
+ "email",
+ "slotId",
+ "confirmationToken",
+ "confirmed"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nextOffset": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "syncStatus": {
+ "enum": [
+ "pending",
+ "ready",
+ "attention"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok"
+ ],
+ "type": "object"
+}cancel_bookingget_booking4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / token / minLengthRemoved value: -8Input schema / properties / token / patternAdded value: +"^[a-f0-9]{64}$"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nextOffset": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "syncStatus": {
+ "enum": [
+ "pending",
+ "ready",
+ "attention"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok"
+ ],
+ "type": "object"
+}get_booking_page3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / slug / maxLengthAdded value: +2048Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nextOffset": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "syncStatus": {
+ "enum": [
+ "pending",
+ "ready",
+ "attention"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok"
+ ],
+ "type": "object"
+}list_available_times9 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / cursorAdded value: +{
+ "pattern": "^s_\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}Z$",
+ "type": "string"
+}Input schema / properties / fromAdded value: +{
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "default": 10,
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / slug / maxLengthAdded value: +2048Input schema / properties / timeOfDayAdded value: +{
+ "enum": [
+ "morning",
+ "afternoon",
+ "evening"
+ ],
+ "type": "string"
+}Input schema / properties / timezoneAdded value: +{
+ "maxLength": 100,
+ "type": "string"
+}Input schema / properties / toAdded value: +{
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nextOffset": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "syncStatus": {
+ "enum": [
+ "pending",
+ "ready",
+ "attention"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok"
+ ],
+ "type": "object"
+}preview_bookingreschedule_bookingbook_meeting1 field changedInput schema / properties / requestIdAdded value: +{
+ "description": "Reuse this ID when retrying the same confirmed booking request.",
+ "format": "uuid",
+ "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+ "type": "string"
+}book_meetingget_bookingget_booking_pagelist_available_timesMerged free/busy, find mutual time, propose bookings with human approval. Never event contents.
Find real businesses and book appointments. Books via Cal.com; imports 12 platforms.
AI-native scheduling and booking: check availability, book meetings, share links.
Book a table, appointment or class at a real local business. Instant confirmation, no API key.
Add one secure layer between your agents and this server.
