Timeplex K-Beauty Booking

start_booking

Read-onlyIdempotent

Build a booking link when the user wants to book, continue a booking, or has asked to check availability for a specific venue or service. Do not call this tool for informational requests such as viewing a venue's menu, prices, service duration, address, or business hours. If the user has booking intent but has not selected a date or time yet, a venue-level booking link may be created. This tool does not create or confirm a booking. Put link_markdown into your reply as-is — never expose the raw URL. The slot is not secured until the customer completes payment, and the booking is only finally confirmed after the shop approves — never imply it is already secured or complete. When a booking link is warranted, do not ask "shall I create a link?" first — create it and include the link in your reply. Pass lang — the language the user is writing in (ko|en|ja|zh) — so the booking card and its notes render in that language. Always reply in the language the user used.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	YYYY-MM-DD (Asia/Seoul). Optional — omit if the customer has not picked a date; they choose it on the booking page.
`lang`	No	Customer language (optional): ko\|en\|ja\|zh. Defaults to en. Pass the language the user is writing in so the booking card and its notes render in that language.
`slug`	Yes	Shop slug returned by search_shops.
`time`	No	HH:MM. Optional — omit if the customer has not picked a time.
`items`	No	Optional — omit if no service is chosen yet. Follow the booking_model returned by get_shop_services: use resource_id for designated-staff shops and qty for capacity-based shops. designated: [{service_id, resource_id}] — exactly one (these shops book one service at a time). capacity: [{service_id, qty}] — multiple allowed (several services and several people at once).

Output Schema

TableJSON Schema

Name	Required	Description
`lang`	No	Language the card content is rendered in (echo of input lang; en fallback). The widget uses it to localize its own labels.
`note`	No	How the slot is secured and finally confirmed — mention this to the customer
`summary`	No	What is preselected on the booking page.
`guidance`	No	Customer-facing summary of the remaining steps — keep it light and pass it on
`confirmed`	Yes	Always false — nothing is booked by this tool
`link_label`	No
`next_steps`	No	What the customer does after opening the link (contact info, payment, shop-owner approval)
`booking_url`	Yes	Prefilled booking page (customer completes contact info + payment there)
`reply_header`	No
`link_markdown`	Yes	Put this into the reply as-is (never expose the raw URL)
`reply_header_usage`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 9, 2026

addedInput schema / properties / lang

Added value: +{
+  "description": "Customer language (optional): ko|en|ja|zh. Defaults to en. Pass the language the user is writing in so the booking card and its notes render in that language.",
+  "type": "string"
+}

addedOutput schema / properties / lang

Added value: +{
+  "description": "Language the card content is rendered in (echo of input lang; en fallback). The widget uses it to localize its own labels.",
+  "type": "string"
+}

Changed5 schema fields changedAug 23, 2026

changedInput schema / properties / items / description

Previous value: -"Optional — omit if no service is chosen yet. Hair: [{service_id, resource_id}] — **exactly one** (hair shops book one service at a time). Massage: [{service_id, qty}] — multiple allowed (several services and several people at once)."New value: +"Optional — omit if no service is chosen yet. Follow the booking_model returned by get_shop_services: use resource_id for designated-staff shops and qty for capacity-based shops. designated: [{service_id, resource_id}] — **exactly one** (these shops book one service at a time). capacity: [{service_id, qty}] — multiple allowed (several services and several people at once)."

addedInput schema / properties / slug / description

Added value: +"Shop slug returned by search_shops."

addedOutput schema / properties / guidance / description

Added value: +"Customer-facing summary of the remaining steps — keep it light and pass it on"

addedOutput schema / properties / next_steps / description

Added value: +"What the customer does after opening the link (contact info, payment, shop-owner approval)"

addedOutput schema / properties / note / description

Added value: +"How the slot is secured and finally confirmed — mention this to the customer"

Changed1 schema field changedAug 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "booking_url": {
+      "description": "Prefilled booking page (customer completes contact info + payment there)",
+      "type": "string"
+    },
+    "confirmed": {
+      "description": "Always false — nothing is booked by this tool",
+      "type": "boolean"
+    },
+    "guidance": {
+      "type": "string"
+    },
+    "link_label": {
+      "type": "string"
+    },
+    "link_markdown": {
+      "description": "Put this into the reply as-is (never expose the raw URL)",
+      "type": "string"
+    },
+    "next_steps": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "note": {
+      "type": "string"
+    },
+    "reply_header": {
+      "type": "string"
+    },
+    "reply_header_usage": {
+      "type": "string"
+    },
+    "summary": {
+      "description": "What is preselected on the booking page.",
+      "properties": {
+        "currency": {
+          "type": "string"
+        },
+        "items": {
+          "items": {
+            "properties": {
+              "currency": {
+                "type": "string"
+              },
+              "duration_min": {
+                "type": [
+                  "integer",
+                  "null"
+                ]
+              },
+              "price": {
+                "type": [
+                  "number",
+                  "string",
+                  "null"
+                ]
+              },
+              "qty": {
+                "type": "integer"
+              },
+              "service": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "staff": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "shop": {
+          "type": "string"
+        },
+        "timezone": {
+          "type": "string"
+        },
+        "total_price": {
+          "type": "number"
+        },
+        "when": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "booking_url",
+    "link_markdown",
+    "confirmed"
+  ],
+  "type": "object"
+}

First observedAug 18, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already mark the tool read-only and idempotent, and the description reinforces this by clarifying that no booking is created or confirmed, the slot is unsecured until payment, and shop approval is still required. It also adds link-handling rules and a language-rendering caveat, going well beyond the annotations.

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

Conciseness4/5

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

The description is dense and front-loaded with the core trigger, and every sentence adds a needed caveat or instruction. It is somewhat long, and the language guidance is repeated from the schema, but there is no real filler.

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

Completeness5/5

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

It covers triggers, non-triggers, the incomplete nature of the booking, link formatting, language handling, and optional-parameter behavior. With an output schema present, no return-value explanation is needed, so nothing important is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description largely restates schema guidance for lang and optional date/time. It adds the venue-level-link context when date/time are omitted, but does not materially extend the parameter meanings beyond what the schema already documents.

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

Purpose5/5

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

The description states a specific verb and resource: 'Build a booking link' and lists the triggering user intents. It distinguishes itself from request_booking by clarifying it 'does not create or confirm a booking' and explicitly excludes informational requests, so an agent can tell it apart from siblings.

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

Usage Guidelines4/5

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

It gives clear when-to-use triggers and explicit when-not-to-use examples ('Do not call this tool for informational requests...'), plus a workflow rule not to ask for permission before creating the link. It does not name a specific sibling tool for informational lookups, so it falls just short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Timeplex K-Beauty Booking tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?