Timeplex K-Beauty Booking

Server Details

Real-time booking for Korean beauty & wellness shops — search availability, get a booking link.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 82 days
Last Tested: 2026-11-07 12:20
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A4.6/5.0

Scored 2026-11-05 09:40 across 5 tools

Disambiguation4/5

The five tools map to distinct steps of a booking funnel (discover shops, read a menu, check slots, create a payment link, request a booking for offline shops), and each description contains explicit DO NOT USE IT FOR boundaries. The only realistic confusion is start_booking vs request_booking, which is mitigated by the bookable=true/false rule but still requires the agent to have read the upstream result correctly.

Naming Consistency5/5

All names are snake_case verb_noun (search_shops, get_shop_services, search_availability, start_booking, request_booking), with the search_*/get_*/start_* prefixes used predictably. No mixed conventions or vague standalone verbs.

Tool Count5/5

Five tools is a clean, minimal surface where each entry corresponds to a real workflow stage and a fallback path for non-bookable shops. Nothing is redundant and nothing feels like an arbitrary split.

Completeness4/5

Discovery, menu/pricing, real-time availability and both online and concierge booking paths are covered, so the pre-purchase flow has no dead ends. The notable gap is post-booking lifecycle: there is no tool to look up, modify or cancel an existing reservation or check its approval status.

Available Tools

5 tools

get_shop_servicesGet Shop ServicesA

Read-onlyIdempotent

Inspect

Get the services, prices, durations, weekly business hours and bookable staff or seats of one specific TimePlex shop (slug from search_shops). USE THIS TOOL WHEN: a shop has been identified and the user asks what it offers, prices, durations or staff; to match requirements (a 60-minute head spa, a budget, two guests at once); or before search_availability / start_booking, which need the service ids and booking_model returned here. DO NOT USE IT FOR: general discovery or recommendations (search_shops), real-time availability (search_availability), or building a booking link (start_booking). SERVICE DATA: describe only the services returned here — never invent names, prices, durations, staff or options, and never assume a service exists because similar shops offer it. Services that cannot be booked online are already excluded. If the requested service is not in the list, say so; do not silently substitute another. Never present medical procedures as TimePlex services. RESOURCES & HOURS: a staff member or seat existing, or the shop being open, does NOT mean it is free at the requested time — only search_availability confirms a slot. NEXT: if the user asked for availability or to book, continue to search_availability with the returned service ids and booking_model instead of stopping at the menu or business hours. If they only asked about the menu, prices or durations, answer from this result and do not check availability or build a booking link unless they ask. A date or time mentioned earlier does not by itself require a slot check. Pass lang to receive the content translated into the customer's language.

Name	Required	Description	Default
`lang`	No	Customer language (optional): ko\|en\|ja\|zh\|th. Defaults to the original text (ko).
`slug`	Yes	Shop slug returned by search_shops

Output Schema

Name	Required	Description
`lang`	No
`note`	No
`shop`	Yes
`services`	Yes
`resources`	No	Staff to designate (designated-staff shops) or seats (capacity-based shops).
`booking_model`	No	How this shop books: 'designated' — pass items as [{service_id, resource_id}]; 'capacity' — pass items as [{service_id, qty}]. Use this for search_availability and start_booking.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the bar is lower; the description still adds non-obvious traits: unbookable services are pre-filtered out of the result, open hours and existing staff do not imply a free slot, no substitution when a service is missing, and lang triggers translated content. It also explains why the returned service ids and booking_model matter downstream.

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?

Front-loaded with the core purpose, then clearly labeled WHEN / DO NOT USE / DATA / NEXT blocks, so an agent can scan to what it needs. The SERVICE DATA and RESOURCES & HOURS sections are somewhat verbose and repeat the same no-invention constraint in several forms, costing a little length.

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?

Output schema exists, so return values need no explanation; the description instead covers what an agent must not infer from the data and where to route next, which is exactly the gap. For a two-parameter read tool with full annotation coverage, nothing needed to call or interpret it 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 description coverage is 100%, so both slug and lang are already documented in the schema, and the description's 'slug from search_shops' and 'Pass lang to receive the content translated' largely restate them. Baseline 3 applies since the schema does the heavy lifting.

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?

Names a specific verb and resource ('Get the services, prices, durations, weekly business hours and bookable staff or seats of one specific TimePlex shop') and pins the input to a slug from search_shops. An agent can distinguish it from search_shops, search_availability, and start_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.

Usage Guidelines5/5

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

Explicit USE THIS TOOL WHEN section covers menu/prices/durations/staff queries and the prerequisite role before search_availability and start_booking, while DO NOT USE IT FOR names each sibling and the condition that selects it. The NEXT paragraph further disambiguates the common failure mode of over-checking availability when the user only asked about the menu.

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

request_bookingRequest BookingAInspect

Use this tool only for a shop that is already in the Timeplex catalog but cannot be booked online yet: a search_shops result with bookable=false, or a newly joined shop whose menu is not registered yet (get_shop_services says so). It submits a booking request for that shop — Timeplex concierge staff contact the shop directly and reply to the customer in their language. Put the returned link_markdown into your reply as-is (never expose the raw URL). Do not use this tool for a shop name that search_shops could not find (shop_name_not_found), and not for generic searches with no matching results — in both cases tell the user it is not on Timeplex instead. For bookable shops use get_shop_services -> search_availability -> start_booking instead.

Name	Required	Description	Default
`lang`	No	Customer language (optional)
`venue_name`	Yes	Name of the shop the customer wants to book

Output Schema

Name	Required	Description
`recorded`	Yes	true — the demand was logged
`link_label`	No
`link_markdown`	No	Markdown link for the reply (see tool description)
`next_step_url`	Yes	Concierge chat where the customer completes the request

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare a non-idempotent, non-destructive write. The description adds substantial context beyond that: the request is handled by human concierge staff who contact the shop directly and reply in the customer's language, so latency and no-immediate-confirmation are implied, plus a hard output constraint to embed the returned link_markdown as-is and never expose the raw URL. The only unaddressed trait is duplicate requests from repeated calls, which is minor against this detail.

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?

Front-loaded with the selection condition, then the action, then output handling, then exclusions and alternatives — a logical order with no filler sentences. It is dense, packing several sibling tool names and error keys into one paragraph, but each clause carries distinct operational information.

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?

Covers selection criteria, the human-in-the-loop behaviour, required output formatting, explicit exclusions, and the alternative path for bookable shops. With only two fully documented parameters and an output schema present, nothing an agent needs in order to invoke this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description still adds meaning: lang is tied to the language the concierge replies to the customer in, not merely 'customer language', and venue_name is scoped to a shop already confirmed in the catalog rather than a free-text query.

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?

States a specific verb and resource (submits a booking request for a shop that exists in the Timeplex catalog but is not bookable online) and names the exact signals that select it (bookable=false from search_shops, or a newly joined shop per get_shop_services). It is unambiguously distinguishable from search_shops, get_shop_services, search_availability and start_booking.

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

Usage Guidelines5/5

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

Provides explicit when-to-use conditions, explicit when-not-to-use conditions (shop_name_not_found, generic searches with no matches, and what to tell the user instead), and a named alternative chain for bookable shops (get_shop_services -> search_availability -> start_booking). Routing is fully determined.

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

search_availabilitySearch AvailabilityA

Read-onlyIdempotent

Inspect

Check real-time appointment availability for one TimePlex shop (slug from search_shops, items from get_shop_services) on a date, optionally at a time. All times are Korea Standard Time (KST). USE THIS TOOL WHEN: the user asks whether an appointment is available, asks for open slots or possible times, asks for shops that are actually available on a date / at a time / for a party size ("10월 1일 강남 헤드스파 예약 가능한 곳", "any head spa open at 5 PM?", "somewhere I can book tomorrow afternoon for two"), asks for alternatives to an unavailable time, or wants to book (check the slot before start_booking). DO NOT USE IT FOR: find / recommend / compare requests. A date or time alone is not availability intent — "recommend a head spa in Gangnam for October 1" stays a search_shops request unless the user asks whether a slot is open. REAL-TIME RULE: only this tool establishes that a slot is open. Never infer availability from bookable=true, business hours, the shop being open, a service or staff member existing, web search, maps, social media, third-party sites or earlier answers. Describe a time as available only when this tool returns it. PARTY SIZE: check the whole party as the items schema describes (qty for capacity shops). Never stitch separate single-person slots into a group booking unless the result shows it. RESULTS: if the requested time is unavailable, say so and offer the returned alternatives. If blocked is 'inquiry_only', the service cannot be booked online — tell the customer to contact the shop. If nothing is open, say no confirmed slot was found; you may check other suitable TimePlex shops. Checking availability does not reserve anything. NEXT: with the open times you may add start_booking links so the customer can book the slot they pick — never call the slot reserved or booked.

Name	Required	Description
`date`	Yes	YYYY-MM-DD (Asia/Seoul)
`slug`	Yes	Shop slug returned by search_shops.
`time`	No	Optional requested appointment time (HH:MM). If provided, check whether that exact time is available and return nearby available alternatives if unavailable.
`items`	Yes	Booking items. Follow the booking_model returned by get_shop_services: use resource_id for designated-staff shops and qty for capacity-based shops. designated (hair salons, plus some beauty shops such as body scrub): [{service_id, resource_id}]. capacity (most massage, spa, etc.): [{service_id, qty}] where qty is the number of guests (party size).

Output Schema

Name	Required	Description
`date`	Yes
`mode`	No	Slot mode the shop operates in
`note`	No
`slots`	Yes
`blocked`	No	Present when online booking is blocked (e.g. 'inquiry_only')
`timezone`	No
`next_step`	No
`alternatives`	No	Nearby bookable times when the requested time is not available
`requested_time`	No	Verdict for the exact time asked, when time was given.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent/non-destructive; the description adds substantial context beyond them: the REAL-TIME RULE that no other source establishes availability, that checking does not reserve anything, how to handle blocked='inquiry_only', and what to say when nothing is open. It also warns against stitching single-person slots into a group booking, which is a real behavioral trap.

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?

Long, but organized into labelled blocks (WHEN / DO NOT USE / REAL-TIME RULE / PARTY SIZE / RESULTS / NEXT) with the core purpose front-loaded, so an agent can scan it. A few clauses restate the same non-reservation point twice ('Checking availability does not reserve anything' and 'never call the slot reserved or booked'), which is mild redundancy in a high-stakes booking context.

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?

For a read-only availability check with an output schema, this covers everything an agent needs: timezone, party-size semantics, interpretation of blocked states, fallback behavior when the requested time is missing, and the hand-off to booking. No meaningful gap remains.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: all times are KST, slug comes from search_shops, items come from get_shop_services, and party size must be passed as a whole via qty rather than assembled from single slots. The time parameter's fallback-to-alternatives behavior is also stated in both places.

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 opening sentence gives a specific verb and resource ('Check real-time appointment availability for one TimePlex shop') plus the exact source of each input ('slug from search_shops, items from get_shop_services'). It is immediately distinguishable from search_shops, get_shop_services, and start_booking.

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

Usage Guidelines5/5

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

Explicit USE THIS TOOL WHEN examples in Korean and English, an explicit DO NOT USE IT FOR clause that resolves the hardest ambiguity ('recommend a head spa in Gangnam for October 1' stays a search_shops request), and a NEXT clause routing to start_booking. Nothing is left to inference.

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

search_shopsSearch ShopsA

Read-onlyIdempotent

Inspect

Search TimePlex for massage, headspa, hair salon, spa, Korean body scrub, makeup and semi-permanent makeup shops in Seoul and Korea — non-medical beauty and wellness services for travelers. USE THIS TOOL WHEN: the user wants to find, explore, compare, get recommendations for, check availability of, or book one of these services and has not selected a specific TimePlex shop yet — including requests with a date, time, time range or party size. Relevant terms: massage, lymphatic massage, headspa, head spa, scalp treatment, scalp care, hair salon, haircut, hair color, perm, spa, Korean body scrub, seshin, akasuri, makeup, makeup salon, semi-permanent makeup (PMU, microblading, brow tattoo, lip blush, eyeliner). Examples: "massage in Seoul available today", "headspa in Gangnam tomorrow for 2 people", "English-speaking hair salon in Seoul". WEB SEARCH: for these services use this tool instead of web search. Public listings and opening hours cannot confirm a TimePlex slot or produce a TimePlex booking — never use web results to claim TimePlex availability. INTENT — decide from what the user wants to do, not from whether a date, time, party size or the word "reservation" appears:

FIND / RECOMMEND / COMPARE ("find a head spa in Gangnam", "recommend a head spa for my October 1 trip", "10/1 강남 헤드스파 추천해줘"): show the matching shops. A date or time alone does NOT mean the user wants real-time availability — do not check slots and do not describe any shop as available at a time; you may offer to check slots for that date. Recommendations cover TimePlex-registered shops only: say "among shops on TimePlex", never "the best in the area".
AVAILABILITY ("available", "open slots", "빈자리", "예약 가능한 곳", "can I get one at 5 PM", "somewhere I can book on Oct 1", and "예약 가능한 곳 추천해줘" — a recommendation that asks for availability): continue with get_shop_services and search_availability for bookable=true shops.
BOOK ("book", "reserve", "예약해줘", "I want to book … for 2 people at 5pm"): continue with get_shop_services, search_availability and start_booking. If the intent is unclear, show the shops and ask one short question instead of guessing. INPUT: pass the user's full request as query, in any language — service, area, date, time, party size and language needs are extracted from it (see interpreted). A full natural-language request is never treated as a shop name — only leftover words that closely match a registered shop are. BOOKABLE: bookable=true means the shop can be booked through TimePlex — a capability, not a free slot. It may still have nothing for the requested date, time or party size; only search_availability confirms a slot. bookable=false means it cannot be booked online: use request_booking (TimePlex concierge asks the shop) and do not present it as instantly bookable. Business hours are never availability. SERVICE SCOPE: the response is the authority on what TimePlex offers (available_service_types). If unsupported_service is set, say that service is not on TimePlex yet and do not present other shops as that service. Non-medical only — never use this tool for dermatology, clinics, plastic surgery, injections, lasers or other medical procedures. SHOP NAMES: if shop_name_not_found is set, say plainly that the named shop is not on TimePlex, then offer the registered shops in the result as alternatives; do not call request_booking for that name. RESULTS: every TimePlex shop supports foreign-language customers through TimePlex multilingual chat, so "English-speaking" / "foreigner-friendly" requests fit this tool. Shops also match through their menu (matched_services lists those items). If no shop is in the requested area the search widens and relaxed says so. Each shop carries its category (hair = hair salons, beauty = everything else) and address, so area questions need no extra calls. note is guidance for you — follow it, do not quote it. State only what the response returns. Always reply in the user's language, and start the reply with the response's reply_header line.

Name	Required	Description
`query`	No	Free-text user request or a specific shop name (optional), in any language. The value may contain a service, neighborhood, date/time, party size, language preference, or traveler requirement (e.g. "foreigner-friendly head spa in Gangnam tomorrow for 2 people"). Recognized service and location terms are extracted before shop-name matching; the value is treated as a shop name only when the remaining words closely match a registered shop.
`location`	No	Area (optional; overrides an area found in query), in English, Korean, Japanese, Chinese or Russian — "Seoul", "Gangnam", "Myeongdong", "Hongdae", "Seongsu", "Busan", "강남", "明洞", "Сеул"… If no shop is in that area, the search widens to the surrounding city (relaxed). Newly joined shops with no address yet are appended with area_match=false.
`service_type`	No	Service (optional; overrides a service found in query). Available on TimePlex now: massage, head spa / scalp treatment, hair salon, spa, Korean body scrub (seshin, akasuri), makeup, semi-permanent makeup (PMU, microblading, brow tattoo) — in English, Korean, Japanese, Chinese or Russian (マッサージ, ヘッドスパ, アカスリ, 按摩, 搓澡, массаж, сесин…). Other services (nail, lash, facial, personal color) are recognized but may return unsupported_service. Leave empty to search all.

Output Schema

Name	Required	Description
`note`	No	Follow-up guidance for the agent
`count`	Yes
`shops`	Yes	Matching shops.
`relaxed`	No	Set when no shop was in the requested area and the search widened: {area:{from,to}}.
`categories`	No
`interpreted`	No	How the request was read: service (massage\|headspa\|hair\|spa\|scrub\|makeup\|…), area, foreigner_friendly, date (YYYY-MM-DD, KST), time, time_range, time_of_day, party_size, gender, attributes, name_query (leftover words treated as a shop name), ignored_terms. Use date/time/party_size for search_availability (party_size → qty).
`reply_header`	No
`filter_applied`	No	How the inputs were interpreted (category/service_type/location/query)
`reply_header_usage`	No
`shop_name_not_found`	No	Set when the user named a specific shop that is not registered on Timeplex. Tell the user that shop is not on Timeplex — do not treat it as a category with zero results, and do not submit it with request_booking.
`unsupported_service`	No	A recognized service that is not on TimePlex yet (e.g. nail, lash, facial, personal_color).
`available_service_types`	No	business_type values currently registered

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses non-obvious semantics that annotations cannot carry: bookable=true is a capability rather than a free slot, bookable=false routes to request_booking, business hours are never availability, searches widen when the area has no shops (relaxed), and unsupported_service / shop_name_not_found are named response states the agent must handle. It also tells the agent not to quote the note field and to state only what the response returns, which is genuine behavioral guidance.

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

Conciseness3/5

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

The content is front-loaded and organized under CAPS headers, but the block is very long for a search tool and repeats itself — the availability-vs-recommendation distinction is restated in the INTENT section, again under BOOKABLE, and again under RESULTS, and the service list appears in both the opening line and SERVICE SCOPE. It remains readable, yet a tighter version could carry the same routing rules in noticeably fewer words.

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?

For a zero-required-parameter router tool sitting alongside booking siblings, the definition covers what an agent needs: trigger conditions, intent branching, input assembly, response-state handling (relaxed, unsupported_service, shop_name_not_found, matched_services, area_match), and a reply-language instruction. Return-value explanation is partly redundant with the output schema, but nothing an agent needs in order 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.

Parameters5/5

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 meaning: the query should carry the user's full natural-language request in any language, and it explains that such a request is never mistaken for a shop name unless leftover words closely match a registered shop. It also clarifies the precedence relationship (explicit location/service_type override values found in query), which is the key semantic an agent needs to choose between passing everything in query versus the discrete fields.

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 opening sentence names a specific verb (search) and a concrete resource set (massage, headspa, hair salon, spa, body scrub, makeup shops) with geography (Seoul/Korea) and a scope boundary (non-medical beauty and wellness). Sibling tools are explicitly referenced (get_shop_services, search_availability, start_booking, request_booking), so the agent can distinguish discovery from 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.

Usage Guidelines5/5

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

A dedicated 'USE THIS TOOL WHEN' block gives the positive trigger, and the INTENT section enumerates three intents (FIND/RECOMMEND/COMPARE, AVAILABILITY, BOOK) each mapped to the next sibling tool to call, plus explicit exclusions (medical/dermatology/clinics) and an instruction to show shops and ask one question when intent is unclear. It even pre-empts web search for these services, which is a real alternative the agent might otherwise pick.

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

start_bookingOpen Booking PageA

Read-onlyIdempotent

Inspect

Build a prefilled TimePlex booking link (Book Now card) for a bookable=true shop. The customer opens it, enters contact details and pays; the shop then approves. Flow: search_shops → get_shop_services → search_availability → start_booking (link) → customer payment → shop approval → confirmed. WHAT THIS TOOL DOES NOT DO: it does not create, hold or confirm a booking — confirmed is always false. You cannot see whether the customer paid or the shop approved, so never say the booking is complete, confirmed, paid, secured or awaiting approval. Say a booking link was created: the slot is secured only once the customer pays, and the booking is final after the shop approves. Never invent a confirmation number or status. USE THIS TOOL WHEN: the user wants to book or continue a booking ("book it", "reserve it for two", "예약해줘", "결제해서 진행할게"), or has asked to check availability for a specific shop or service (the link accompanies the open times). Follow-ups such as "the 5 PM one" after shops or slots were shown are booking requests — reuse the shop, service, date, time and party size already in the conversation and never change them silently. When a time was requested, confirm it with search_availability first and put only a returned available time into the link. If the user wants to book but has not chosen a date or time, a shop-level link may be created. When a link is warranted, create it — do not ask "shall I create a link?" first. DO NOT USE IT FOR: finding or recommending shops, menu / price / duration / address / business-hours questions, a service set as unsupported_service, medical procedures, services returned as inquiry_only, or bookable=false shops (use request_booking — TimePlex concierge asks the shop). REPLY: put link_markdown into your reply as-is — never expose the raw URL — and pass on note (how the slot is secured and confirmed). Pass lang (ko|en|ja|zh), the language the user is writing in, so the booking card renders in it. Always reply in the language the user used.

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

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

TDQS

A4.6/5.0

Behavior4/5

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

Despite annotations already declaring readOnlyHint/idempotent/non-destructive, the description adds substantial behavioral context the annotations cannot convey: it does not create, hold or confirm a booking, confirmed is always false, and the agent cannot observe payment or shop approval, so it must never claim the booking is secured. It also discloses the reply contract (embed link_markdown as-is, never the raw URL). It stops short of describing the return payload/shape, but with an output schema present that is a minor gap.

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?

Heavy but well organized with front-loaded purpose, then WHEN/NOT-FOR/REPLY blocks, so an agent can skim the relevant section. It is somewhat overstuffed with parenthetical example utterances and repeated language instructions, which cost a point on tightness.

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?

For a 5-parameter tool with an output schema, the definition covers the decision context (when a link is warranted), the constraints on inputs, the correct post-call phrasing, and the failure modes to avoid inventing. Nothing material is missing for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it constrains time to a value returned by search_availability, warns against silently changing date/time/party size carried over from conversation, and explains that items follow the booking_model from get_shop_services. It also gives the rationale for lang (renders the booking card in the user's language).

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 names a specific verb and resource — build a prefilled TimePlex booking link (Book Now card) for a bookable=true shop — and immediately frames what happens next (customer opens, pays, shop approves). It is clearly distinguishable from the sibling request_booking, which is named as the alternative for non-bookable cases.

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

Usage Guidelines5/5

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

It gives an explicit pipeline (search_shops → get_shop_services → search_availability → start_booking), a WHEN section with concrete trigger phrases including follow-ups like 'the 5 PM one', and a DO NOT USE section listing exclusions: unsupported_service, inquiry_only, bookable=false (use request_booking), and non-booking informational queries. It even settles the meta-question by instructing not to ask permission before creating a link.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesNov 1, 2026

Changedget_shop_services11 fields changed

addedOutput schema / properties / booking_model / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / booking_model / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
addedOutput schema / properties / services / items / properties / duration_min / anyOf
```
Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
removedOutput schema / properties / services / items / properties / duration_min / type
```
Removed value: -[
-  "integer",
-  "null"
-]
```

addedOutput schema / properties / services / items / properties / price / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / services / items / properties / price / type
```
Removed value: -[
-  "number",
-  "string",
-  "null"
-]
```

addedOutput schema / properties / shop / properties / business_hours / anyOf

Added value: +[
+  {
+    "items": {
+      "properties": {
+        "close": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "closed": {
+          "description": "true = closed that weekday",
+          "type": "boolean"
+        },
+        "open": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / shop / properties / business_hours / items

Removed value: -{
-  "properties": {
-    "close": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "closed": {
-      "description": "true = closed that weekday",
-      "type": "boolean"
-    },
-    "open": {
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}

removedOutput schema / properties / shop / properties / business_hours / type
```
Removed value: -[
-  "array",
-  "null"
-]
```

addedOutput schema / properties / shop / properties / business_type / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / shop / properties / business_type / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

Changedrequest_booking2 fields changed

removedOutput schema / properties / instruction
```
Removed value: -{
-  "type": "string"
-}
```

changedOutput schema / properties / link_markdown / description

Previous value: -"Put this into the reply as-is (never expose the raw URL)"New value: +"Markdown link for the reply (see tool description)"

Changedsearch_shops13 fields changed

addedOutput schema / properties / relaxed / anyOf

Added value: +[
+  {
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / relaxed / type
```
Removed value: -[
-  "object",
-  "null"
-]
```

addedOutput schema / properties / shop_name_not_found / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / shop_name_not_found / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

addedOutput schema / properties / shops / items / properties / address / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / shops / items / properties / address / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

addedOutput schema / properties / shops / items / properties / business_type / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / shops / items / properties / business_type / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

addedOutput schema / properties / shops / items / properties / business_type_label / anyOf

Added value: +[
+  {
+    "properties": {
+      "en": {
+        "type": "string"
+      },
+      "ko": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / shops / items / properties / business_type_label / properties

Removed value: -{
-  "en": {
-    "type": "string"
-  },
-  "ko": {
-    "type": "string"
-  }
-}

removedOutput schema / properties / shops / items / properties / business_type_label / type
```
Removed value: -[
-  "object",
-  "null"
-]
```

addedOutput schema / properties / unsupported_service / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / unsupported_service / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

Changedstart_booking10 fields changed
- addedOutput schema / properties / summary / properties / items / items / properties / duration_min / anyOf
```
Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / summary / properties / items / items / properties / duration_min / type
```
Removed value: -[
-  "integer",
-  "null"
-]
```
- addedOutput schema / properties / summary / properties / items / items / properties / price / anyOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / summary / properties / items / items / properties / price / type
```
Removed value: -[
-  "number",
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / summary / properties / items / items / properties / service / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / summary / properties / items / items / properties / service / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / summary / properties / items / items / properties / staff / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / summary / properties / items / items / properties / staff / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / summary / properties / when / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / summary / properties / when / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

1 tool updateSep 27, 2026

Changedsearch_shops2 fields changed

changedInput schema / properties / location / description

Previous value: -"Area (optional; overrides an area found in query), in English, Korean, Japanese or Chinese — \"Seoul\", \"Gangnam\", \"Myeongdong\", \"Hongdae\", \"Seongsu\", \"Busan\", \"강남\", \"明洞\"… If no shop is in that area, the search widens to the surrounding city (relaxed). Newly joined shops with no address yet are appended with area_match=false."New value: +"Area (optional; overrides an area found in query), in English, Korean, Japanese, Chinese or Russian — \"Seoul\", \"Gangnam\", \"Myeongdong\", \"Hongdae\", \"Seongsu\", \"Busan\", \"강남\", \"明洞\", \"Сеул\"… If no shop is in that area, the search widens to the surrounding city (relaxed). Newly joined shops with no address yet are appended with area_match=false."

changedInput schema / properties / service_type / description

Previous value: -"Service (optional; overrides a service found in query). Available on TimePlex now: massage, head spa / scalp treatment, hair salon, spa, Korean body scrub (seshin, akasuri), makeup, semi-permanent makeup (PMU, microblading, brow tattoo) — in English, Korean, Japanese or Chinese (マッサージ, ヘッドスパ, アカスリ, 按摩, 搓澡…). Other services (nail, lash, facial, personal color) are recognized but may return unsupported_service. Leave empty to search all."New value: +"Service (optional; overrides a service found in query). Available on TimePlex now: massage, head spa / scalp treatment, hair salon, spa, Korean body scrub (seshin, akasuri), makeup, semi-permanent makeup (PMU, microblading, brow tattoo) — in English, Korean, Japanese, Chinese or Russian (マッサージ, ヘッドスパ, アカスリ, 按摩, 搓澡, массаж, сесин…). Other services (nail, lash, facial, personal color) are recognized but may return unsupported_service. Leave empty to search all."

2 tool updatesSep 25, 2026

Changedsearch_availability1 field changed

changedInput schema / properties / items / description

Previous value: -"Booking items. Follow the booking_model returned by get_shop_services: use resource_id for designated-staff shops and qty for capacity-based shops. designated (hair salons, plus some beauty shops such as body scrub): [{service_id, resource_id}]. capacity (most massage, spa, etc.): [{service_id, qty}] where qty is the number of people."New value: +"Booking items. Follow the booking_model returned by get_shop_services: use resource_id for designated-staff shops and qty for capacity-based shops. designated (hair salons, plus some beauty shops such as body scrub): [{service_id, resource_id}]. capacity (most massage, spa, etc.): [{service_id, qty}] where qty is the number of guests (party size)."

Changedsearch_shops7 fields changed

changedInput schema / properties / location / description

Previous value: -"Area filter (optional), in English or Korean — \"Seoul\", \"Gangnam\", \"Hongdae\", \"Busan\", \"Jeju\", \"강남\", \"홍대\"… Matched against the shop address. Shops with no address registered are excluded when this is set."New value: +"Area (optional; overrides an area found in query), in English, Korean, Japanese or Chinese — \"Seoul\", \"Gangnam\", \"Myeongdong\", \"Hongdae\", \"Seongsu\", \"Busan\", \"강남\", \"明洞\"… If no shop is in that area, the search widens to the surrounding city (relaxed). Newly joined shops with no address yet are appended with area_match=false."

changedInput schema / properties / query / description

Previous value: -"Shop name, service, or natural-language search term (optional). If no shop name matches, it is also interpreted as a service/category search."New value: +"Free-text user request or a specific shop name (optional), in any language. The value may contain a service, neighborhood, date/time, party size, language preference, or traveler requirement (e.g. \"foreigner-friendly head spa in Gangnam tomorrow for 2 people\"). Recognized service and location terms are extracted before shop-name matching; the value is treated as a shop name only when the remaining words closely match a registered shop."

changedInput schema / properties / service_type / description

Previous value: -"Shop category (optional). Accepts broad categories (\"hair\", \"beauty\") and specific ones (\"massage\", \"spa\", \"head spa\", \"nail\", \"skincare\", \"facial\", \"esthetic\", \"waxing\", \"scrub\"), in English, Korean, Japanese or Chinese (アカスリ, ヘッドスパ, マッサージ, 搓澡, 头皮护理, 按摩…). Leave empty to search all categories."New value: +"Service (optional; overrides a service found in query). Available on TimePlex now: massage, head spa / scalp treatment, hair salon, spa, Korean body scrub (seshin, akasuri), makeup, semi-permanent makeup (PMU, microblading, brow tattoo) — in English, Korean, Japanese or Chinese (マッサージ, ヘッドスパ, アカスリ, 按摩, 搓澡…). Other services (nail, lash, facial, personal color) are recognized but may return unsupported_service. Leave empty to search all."

addedOutput schema / properties / interpreted

Added value: +{
+  "description": "How the request was read: service (massage|headspa|hair|spa|scrub|makeup|…), area, foreigner_friendly, date (YYYY-MM-DD, KST), time, time_range, time_of_day, party_size, gender, attributes, name_query (leftover words treated as a shop name), ignored_terms. Use date/time/party_size for search_availability (party_size → qty).",
+  "type": "object"
+}

addedOutput schema / properties / relaxed

Added value: +{
+  "description": "Set when no shop was in the requested area and the search widened: {area:{from,to}}.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / shops / items / properties / matched_services

Added value: +{
+  "description": "Present when the shop matched through its menu: the menu items (original names) that matched the request. Pick the service from these in get_shop_services.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / unsupported_service

Added value: +{
+  "description": "A recognized service that is not on TimePlex yet (e.g. nail, lash, facial, personal_color).",
+  "type": [
+    "string",
+    "null"
+  ]
+}

1 tool updateSep 9, 2026

Changedstart_booking2 fields changed

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"
+}

1 tool updateAug 24, 2026

Changedsearch_shops2 fields changed

addedOutput schema / properties / shops / items / properties / business_type / description
```
Added value: +"Filter code. Use business_type_label when naming the shop to the user."
```

addedOutput schema / properties / shops / items / properties / business_type_label

Added value: +{
+  "description": "Display label the shop selected (spa = 스파·헤드스파 / spa & head spa). null when unset.",
+  "properties": {
+    "en": {
+      "type": "string"
+    },
+    "ko": {
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

1 tool updateAug 24, 2026

Changedsearch_shops1 field changed

changedInput schema / properties / service_type / description

Previous value: -"Shop category (optional). Accepts broad categories (\"hair\", \"beauty\") and specific ones (\"massage\", \"spa\", \"head spa\", \"nail\", \"skincare\", \"facial\", \"esthetic\", \"waxing\", \"scrub\"), in English or Korean. Leave empty to search all categories."New value: +"Shop category (optional). Accepts broad categories (\"hair\", \"beauty\") and specific ones (\"massage\", \"spa\", \"head spa\", \"nail\", \"skincare\", \"facial\", \"esthetic\", \"waxing\", \"scrub\"), in English, Korean, Japanese or Chinese (アカスリ, ヘッドスパ, マッサージ, 搓澡, 头皮护理, 按摩…). Leave empty to search all categories."

2 tool updatesAug 24, 2026

Changedget_shop_services4 fields changed

addedOutput schema / properties / resources / items / properties / service_ids

Added value: +{
+  "description": "Services this staff/seat handles. Empty = handles every service. Pass this resource only for a service in this list.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / shop / properties / business_hours / description

Added value: +"Weekly hours, index 0 = Sunday: [{open:\"10:30\", close:\"21:00\", closed:false} × 7]"

addedOutput schema / properties / shop / properties / business_hours / items

Added value: +{
+  "properties": {
+    "close": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "closed": {
+      "description": "true = closed that weekday",
+      "type": "boolean"
+    },
+    "open": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

changedOutput schema / properties / shop / properties / business_hours / type

Previous value: -[
-  "object",
-  "null"
-]New value: +[
+  "array",
+  "null"
+]

Changedsearch_shops1 field changed

addedOutput schema / properties / shop_name_not_found

Added value: +{
+  "description": "Set when the user named a specific shop that is not registered on Timeplex. Tell the user that shop is not on Timeplex — do not treat it as a category with zero results, and do not submit it with request_booking.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

1 tool updateAug 23, 2026
- Removedget_booking_status

4 tool updatesAug 23, 2026

Changedget_shop_services2 fields changed

addedOutput schema / properties / booking_model

Added value: +{
+  "description": "How this shop books: 'designated' — pass items as [{service_id, resource_id}]; 'capacity' — pass items as [{service_id, qty}]. Use this for search_availability and start_booking.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / resources / description

Previous value: -"Staff (hair) or seats (massage)."New value: +"Staff to designate (designated-staff shops) or seats (capacity-based shops)."

Changedsearch_availability3 fields changed

changedInput schema / properties / items / description

Previous value: -"Booking items. Hair: [{service_id, resource_id}]. Massage: [{service_id, qty}] (qty = number of people)."New value: +"Booking items. Follow the booking_model returned by get_shop_services: use resource_id for designated-staff shops and qty for capacity-based shops. designated (hair salons, plus some beauty shops such as body scrub): [{service_id, resource_id}]. capacity (most massage, spa, etc.): [{service_id, qty}] where qty is the number of people."

addedInput schema / properties / slug / description

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

changedInput schema / properties / time / description

Previous value: -"HH:MM (optional) — judge whether this exact time is bookable"New value: +"Optional requested appointment time (HH:MM). If provided, check whether that exact time is available and return nearby available alternatives if unavailable."

Changedsearch_shops4 fields changed

changedInput schema / properties / query / description

Previous value: -"Shop name, partial match (optional). If no name matches, it is also interpreted as a shop category."New value: +"Shop name, service, or natural-language search term (optional). If no shop name matches, it is also interpreted as a service/category search."

changedInput schema / properties / service_type / description

Previous value: -"Shop category (optional). Accepts broad categories (\"hair\", \"beauty\") and specific ones (\"massage\", \"spa\", \"head spa\", \"nail\", \"skin care\", \"esthetic\", \"waxing\", \"scrub\"), in English or Korean. Leave empty to search all categories."New value: +"Shop category (optional). Accepts broad categories (\"hair\", \"beauty\") and specific ones (\"massage\", \"spa\", \"head spa\", \"nail\", \"skincare\", \"facial\", \"esthetic\", \"waxing\", \"scrub\"), in English or Korean. Leave empty to search all categories."

addedOutput schema / properties / shops / items / properties / address / description
```
Added value: +"null = newly joined shop that has not registered an address yet"
```

addedOutput schema / properties / shops / items / properties / area_match

Added value: +{
+  "description": "Present only when a location filter was applied: true = address matched the area; false = no address registered yet (newly onboarding) — confirm the area with the shop",
+  "type": "boolean"
+}

Changedstart_booking5 fields changed

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"

6 tool updatesAug 22, 2026

Changedget_booking_status1 field changed