Timeplex K-Beauty Booking
Server Details
Real-time booking for Korean beauty & wellness shops — search availability, get a booking link.
- Status
- Healthy
- Uptime
- 99.9% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 5 tools
Each tool maps to a distinct stage of the booking funnel: search_shops (discover), get_shop_services (menu), search_availability (slots), start_booking (bookable flow), request_booking (manual/concierge flow). The only potentially confusable pair, start_booking vs request_booking, is explicitly disambiguated by descriptions that route bookable=true shops to start_booking and bookable=false shops to request_booking.
All five tools use a consistent snake_case verb_noun pattern (get_shop_services, request_booking, search_availability, search_shops, start_booking). Verb choices (search/get/start/request) are natural and follow a predictable convention.
Five tools is well-scoped for a booking domain, with each tool earning its place across the discover→inspect→check→book lifecycle. No redundancy or filler tools.
The core booking funnel is fully covered, including the manual-request path for non-bookable shops. Minor gaps exist around post-booking lifecycle operations such as viewing, canceling, or rescheduling an existing booking, which an agent might need later.
Available Tools
5 toolsget_shop_servicesARead-onlyIdempotentInspect
Get the available services, prices, durations, and bookable staff or resources for a specific TimePlex beauty or wellness shop. Use this after search_shops when service details, prices, durations, staff, resources, or bookable items are needed before checking appointment availability. If the user has asked to book or check availability, use the returned service/item IDs and booking_model to continue to search_availability rather than stopping after showing the menu or business hours. 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat those. It adds useful behavioral context beyond annotations: the response is localization-aware via lang, and the returned booking_model/service/item IDs are meant to be consumed downstream by search_availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and every sentence carries useful routing information. It is slightly verbose with repeated detail lists, but remains readable and efficient enough for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the annotations are rich, and the workflow position is clearly defined, the description covers what an agent needs: when to call it, what it returns conceptually, and how to continue to search_availability. No critical usage gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds marginal context by noting slug comes from search_shops and that lang controls translation, but it does not substantially expand on the structured parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get the available services, prices, durations, and bookable staff or resources') and a clear resource ('a specific TimePlex beauty or wellness shop'). It is immediately distinguishable from siblings like search_shops and search_availability by naming exactly what data it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use the tool: 'after search_shops' and 'when service details, prices, durations, staff, resources, or bookable items are needed before checking appointment availability.' It also names the alternative path, directing continued workflow to search_availability and warning against stopping after showing the menu or business hours.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_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. Share the returned link with the user. 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 | |
| instruction | No | |
| link_markdown | No | Put this into the reply as-is (never expose the raw URL) |
| next_step_url | Yes | Concierge chat where the customer completes the request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (not read-only, not idempotent, not destructive), so the description carries the full burden. It discloses that the request goes to concierge staff who contact the shop directly, that it is asynchronous, and that the returned link should be shared with the user. This is valuable context beyond the schema and hints. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and condition, then proceeds through the workflow, the action (share the link), and the exclusions. Every sentence contributes: no filler, no repetition. It's long but efficiently organized—exactly what an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists (has output schema: true), so exhaustive return-value detail isn't required. The description covers the essential outcomes (e.g., the returned link) and error scenarios (shop_name_not_found). For a two-parameter tool with clear usage, nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters already have descriptive self-documentation (e.g., 'Name of the shop the customer wants to book'). The description adds no parameter-specific details beyond what the schema provides, so the baseline of 3 applies. It does clarify that venue_name refers to a non-bookable shop, but that is usage context, not parameter 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 ('submits a booking request') and a clear resource (a shop that is in the Timeplex catalog but cannot be booked online). It contrasts directly with siblings like start_booking and search_shops, leaving no ambiguity about which tool to pick for non-bookable shops.
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?
Explicit when-to-use (bookable=false or newly joined shop without registered menu) and when-not-to-use (shop_name_not_found or generic no-match). It even names the alternative workflow for bookable shops (get_shop_services -> search_availability -> start_booking). This is the gold standard for routing an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_availabilityARead-onlyIdempotentInspect
Check actual real-time appointment availability and bookable time slots for a specific TimePlex beauty or wellness shop. Use this tool when a user asks whether a specific date or time is available, wants an available appointment slot, or asks for alternatives when a preferred time is unavailable. Business opening hours do not mean an appointment slot is available. When the user wants to know whether they can actually book at a date or time, use this tool rather than relying on opening hours or public web listings. Returns available times and nearby alternatives when the requested time is unavailable. All times are in Korea Standard Time (KST).
| Name | Required | Description | Default |
|---|---|---|---|
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds timezone (KST) and the behavior that nearby alternatives are returned if the requested time is unavailable. However, it does not explicitly state what happens when the optional 'time' parameter is omitted (e.g., returns all available times for the day). This minor gap prevents a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the core purpose, then usage guidance, a key caution about opening hours, output behavior, and timezone. Each sentence earns its place; there is no fluff. Length is appropriate given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, timezone, and output hints. An output schema is present so return values are handled there. The only missing piece is the behavior when no time is provided; this is inferred but not explicitly stated. Otherwise, the description is thorough and integrates well with annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description goes further by explaining the items parameter semantics: using resource_id for designated-staff shops and qty for capacity-based shops, referencing the booking_model from get_shop_services. It also clarifies that the time parameter triggers a check with alternatives if unavailable. This adds significant value beyond 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 clearly states the tool checks real-time appointment availability for a specific shop, naming the verb 'check' and the resource 'appointment availability and bookable time slots.' This distinguishes it from siblings like get_shop_services (services) and request_booking/start_booking (booking). The focus on availability is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this tool when a user asks whether a specific date or time is available, wants an available appointment slot, or asks for alternatives when a preferred time is unavailable.' It also warns against relying on opening hours, effectively excluding a common wrong alternative, and implicitly directs booking actions to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_shopsARead-onlyIdempotentInspect
Search TimePlex for massage, headspa, hair salon, spa, Korean body scrub, and makeup shops in Seoul and Korea — non-medical beauty and wellness services for travelers. Use this tool as the first step when a user wants to find, compare, or book a service but has not selected a specific TimePlex shop yet, including requests asking what is available today, tomorrow, on a specific date or time, within a time range, or for multiple guests. Examples include "massage in Seoul available today", "lymphatic massage near Hongdae", "headspa in Gangnam tomorrow for 2 people", "scalp treatment in Myeongdong", "English-speaking hair salon in Seoul", "hair color in Myeongdong", "spa available tomorrow", "Korean body scrub in Seoul", and "Korean makeup in Seoul". Relevant user terms include 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, and semi-permanent makeup (PMU, microblading, brow tattoo, lip blush, eyeliner). Pass the user's request as query, in any language: the service, area, date, time, party size and language needs are extracted from it (see interpreted in the response). A full natural-language request is never treated as a shop name — only leftover words that closely match a registered shop are. Every TimePlex shop supports foreign-language customers through TimePlex multilingual chat, so requests for English-speaking or foreigner-friendly shops are a good fit for this tool. Shops are also matched by their menu (e.g. a hair salon with a scalp-care menu is returned for headspa); matched_services lists those menu items. If no shop is in the requested area, the search widens to the surrounding city and relaxed says so. This tool is for non-medical services only — do not use it for dermatology, clinics, plastic surgery, injections, lasers, or other medical procedures. This tool finds matching TimePlex shops; it does not by itself confirm an appointment slot. For bookable=true shops, continue with get_shop_services and search_availability to check actual booking availability. Do not treat business opening hours as proof that an appointment is available. Results indicate whether each shop is bookable through TimePlex: bookable=true means real-time availability can be checked and the customer can proceed to booking through this MCP; bookable=false means it needs request_booking (TimePlex concierge arranges it manually). Shops fall into two categories: hair (hair salons) and beauty (everything else). Each shop result carries its category. If the user named a specific shop that is not registered, the response sets shop_name_not_found — tell the user that shop is not on TimePlex and offer the registered shops in the result as alternatives. If unsupported_service is set, that kind of service is not on TimePlex yet — say so instead of offering other shops. Each result carries the shop address, so you can answer area questions ("shops in Seoul") without extra calls. Always reply to the user in the language they used, and start the reply with the response's reply_header line.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavioral context beyond them: bookable=true vs false routing to request_booking, shop_name_not_found and unsupported_service signals, relaxed widening, and the reply_header convention. This is rich disclosure of edge-case behavior.
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?
It is front-loaded with purpose and scope, and each block carries operational value (routing, error flags, next steps). However, the enumeration of example phrases and synonym lists is long enough that the core instruction is somewhat buried; minor trimming would sharpen it.
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 search tool over a domain with several distinct response flags, the description covers service scope, language handling, widening behavior, error signals, and next-step routing. With an output schema present, no return-value explanation is needed, so the definition is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters and the baseline of 3 applies. The description still adds meaning beyond it: that query is parsed for service/area/date/party-size/language, that location and service_type override values found in query, and that a natural-language request is never treated as a shop name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Search TimePlex for massage, headspa, hair salon, spa, Korean body scrub, and makeup shops in Seoul and Korea') and frames the domain precisely. It distinguishes itself from siblings by declaring it is 'the first step' in discovery versus booking, making the boundary with get_shop_services/search_availability explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use it (user wants to find/compare/book but hasn't picked a shop, including date/time/party-size variants) and names the follow-on tools ('continue with get_shop_services and search_availability'). Negative guidance is equally explicit: no medical/dermatology/plastic surgery, and it warns not to treat opening hours as booking proof.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_bookingARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
search_shops2 fields changed- changed
Input schema / properties / location / descriptionPrevious 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." - changed
Input schema / properties / service_type / descriptionPrevious 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 updates
- Changed
search_availability1 field changed- changed
Input schema / properties / items / descriptionPrevious 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)."
- Changed
search_shops7 fields changed- changed
Input schema / properties / location / descriptionPrevious 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." - changed
Input schema / properties / query / descriptionPrevious 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." - changed
Input schema / properties / service_type / descriptionPrevious 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." - added
Output schema / properties / interpretedAdded 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" +} - added
Output schema / properties / relaxedAdded value: +{ + "description": "Set when no shop was in the requested area and the search widened: {area:{from,to}}.", + "type": [ + "object", + "null" + ] +} - added
Output schema / properties / shops / items / properties / matched_servicesAdded 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" +} - added
Output schema / properties / unsupported_serviceAdded value: +{ + "description": "A recognized service that is not on TimePlex yet (e.g. nail, lash, facial, personal_color).", + "type": [ + "string", + "null" + ] +}
1 tool update
- Changed
start_booking2 fields changed- added
Input schema / properties / langAdded 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" +} - added
Output schema / properties / langAdded 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 update
- Changed
search_shops2 fields changed- added
Output schema / properties / shops / items / properties / business_type / descriptionAdded value: +"Filter code. Use business_type_label when naming the shop to the user." - added
Output schema / properties / shops / items / properties / business_type_labelAdded 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 update
- Changed
search_shops1 field changed- changed
Input schema / properties / service_type / descriptionPrevious 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 updates
- Changed
get_shop_services4 fields changed- added
Output schema / properties / resources / items / properties / service_idsAdded 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" +} - added
Output schema / properties / shop / properties / business_hours / descriptionAdded value: +"Weekly hours, index 0 = Sunday: [{open:\"10:30\", close:\"21:00\", closed:false} × 7]" - added
Output schema / properties / shop / properties / business_hours / itemsAdded value: +{ + "properties": { + "close": { + "type": [ + "string", + "null" + ] + }, + "closed": { + "description": "true = closed that weekday", + "type": "boolean" + }, + "open": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +} - changed
Output schema / properties / shop / properties / business_hours / typePrevious value: -[ - "object", - "null" -]New value: +[ + "array", + "null" +]
- Changed
search_shops1 field changed- added
Output schema / properties / shop_name_not_foundAdded 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 update
- Removed
get_booking_status
4 tool updates
- Changed
get_shop_services2 fields changed- added
Output schema / properties / booking_modelAdded 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" + ] +} - changed
Output schema / properties / resources / descriptionPrevious value: -"Staff (hair) or seats (massage)."New value: +"Staff to designate (designated-staff shops) or seats (capacity-based shops)."
- Changed
search_availability3 fields changed- changed
Input schema / properties / items / descriptionPrevious 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." - added
Input schema / properties / slug / descriptionAdded value: +"Shop slug returned by search_shops." - changed
Input schema / properties / time / descriptionPrevious 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."
- Changed
search_shops4 fields changed- changed
Input schema / properties / query / descriptionPrevious 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." - changed
Input schema / properties / service_type / descriptionPrevious 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." - added
Output schema / properties / shops / items / properties / address / descriptionAdded value: +"null = newly joined shop that has not registered an address yet" - added
Output schema / properties / shops / items / properties / area_matchAdded 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" +}
- Changed
start_booking5 fields changed- changed
Input schema / properties / items / descriptionPrevious 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)." - added
Input schema / properties / slug / descriptionAdded value: +"Shop slug returned by search_shops." - added
Output schema / properties / guidance / descriptionAdded value: +"Customer-facing summary of the remaining steps — keep it light and pass it on" - added
Output schema / properties / next_steps / descriptionAdded value: +"What the customer does after opening the link (contact info, payment, shop-owner approval)" - added
Output schema / properties / note / descriptionAdded value: +"How the slot is secured and finally confirmed — mention this to the customer"
6 tool updates
- Changed
get_booking_status1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "bookings": { + "items": { + "properties": { + "service": { + "type": [ + "string", + "null" + ] + }, + "staff": { + "type": [ + "string", + "null" + ] + }, + "status": { + "type": [ + "string", + "null" + ] + }, + "when": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "cancel": { + "description": "Whether cancellation is possible and the refund terms", + "type": [ + "object", + "null" + ] + }, + "payment": { + "description": "Payment status summary (no card data)", + "type": [ + "object", + "null" + ] + }, + "phase": { + "description": "Overall reservation phase", + "type": "string" + }, + "reservation_no": { + "type": "string" + }, + "shop": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "type": [ + "object", + "null" + ] + }, + "status_url": { + "description": "Customer-facing status page (cancelling happens there, not via MCP)", + "type": "string" + }, + "totals": { + "type": [ + "object", + "null" + ] + } + }, + "required": [ + "status_url" + ], + "type": "object" +}
- Changed
get_shop_services1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "lang": { + "type": "string" + }, + "note": { + "type": "string" + }, + "resources": { + "description": "Staff (hair) or seats (massage).", + "items": { + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "services": { + "items": { + "properties": { + "currency": { + "type": "string" + }, + "duration_min": { + "type": [ + "integer", + "null" + ] + }, + "id": { + "description": "Pass as items[].service_id to search_availability / start_booking", + "type": "string" + }, + "name": { + "type": "string" + }, + "price": { + "type": [ + "number", + "string", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "shop": { + "properties": { + "address": { + "type": "string" + }, + "business_hours": { + "type": [ + "object", + "null" + ] + }, + "business_type": { + "type": [ + "string", + "null" + ] + }, + "map_url": { + "type": "string" + }, + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "type": "object" + } + }, + "required": [ + "shop", + "services" + ], + "type": "object" +}
- Changed
request_booking1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "instruction": { + "type": "string" + }, + "link_label": { + "type": "string" + }, + "link_markdown": { + "description": "Put this into the reply as-is (never expose the raw URL)", + "type": "string" + }, + "next_step_url": { + "description": "Concierge chat where the customer completes the request", + "type": "string" + }, + "recorded": { + "description": "true — the demand was logged", + "type": "boolean" + } + }, + "required": [ + "recorded", + "next_step_url" + ], + "type": "object" +}
- Changed
search_availability1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "alternatives": { + "description": "Nearby bookable times when the requested time is not available", + "items": { + "type": "string" + }, + "type": "array" + }, + "blocked": { + "description": "Present when online booking is blocked (e.g. 'inquiry_only')", + "type": "string" + }, + "date": { + "type": "string" + }, + "mode": { + "description": "Slot mode the shop operates in", + "type": "string" + }, + "next_step": { + "type": "string" + }, + "note": { + "type": "string" + }, + "requested_time": { + "description": "Verdict for the exact time asked, when time was given.", + "properties": { + "available": { + "type": "boolean" + }, + "time": { + "type": "string" + } + }, + "type": "object" + }, + "slots": { + "items": { + "properties": { + "available": { + "type": "boolean" + }, + "time": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "timezone": { + "type": "string" + } + }, + "required": [ + "date", + "slots" + ], + "type": "object" +}
- Changed
search_shops1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "available_service_types": { + "description": "business_type values currently registered", + "items": { + "type": "string" + }, + "type": "array" + }, + "categories": { + "items": { + "type": "string" + }, + "type": "array" + }, + "count": { + "type": "integer" + }, + "filter_applied": { + "description": "How the inputs were interpreted (category/service_type/location/query)", + "type": "object" + }, + "note": { + "description": "Follow-up guidance for the agent", + "type": "string" + }, + "reply_header": { + "type": "string" + }, + "reply_header_usage": { + "type": "string" + }, + "shops": { + "description": "Matching shops.", + "items": { + "properties": { + "address": { + "type": [ + "string", + "null" + ] + }, + "bookable": { + "description": "true = bookable via this MCP; false = use request_booking", + "type": "boolean" + }, + "business_type": { + "type": [ + "string", + "null" + ] + }, + "category": { + "enum": [ + "hair", + "beauty" + ], + "type": "string" + }, + "name": { + "type": "string" + }, + "slug": { + "description": "Shop id for the other tools", + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "shops", + "count" + ], + "type": "object" +}
- Changed
start_booking1 field changed- changed
Output 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" +}
6 tool updates
- First observed
get_booking_status - First observed
get_shop_services - First observed
request_booking - First observed
search_availability - First observed
search_shops - First observed
start_booking
Related MCP Connectors
Search and book appointments at local businesses. Barbershops, salons, spas, and more.
Book a table, appointment or class at a real local business. Instant confirmation, no API key.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Search and book appointments at service businesses across Uzbekistan.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables users to query real-time reservation availability for Naver Booking places in Korea, including beauty salons, restaurants, and other categories.-
- AlicenseNot gradedqualityNot gradedmaintenanceConnects AI models to real-time search and inventory data for major South Korean retail chains, convenience stores, and cinemas. It enables users to check product availability at stores like Daiso and Olive Young, or view movie schedules at CGV and Megabox.309 npm-
- AlicenseNot gradedqualityDmaintenanceProvides comprehensive Korean Beauty information through real-time web search, AI-powered skin analysis from photos, and curated knowledge of 58+ K-Beauty brands, ingredients, and personalized skincare routines.8MIT
- FlicenseNot gradedqualityDmaintenanceEnables unified management of reservations across multiple Korean platforms (Naver, Airbnb, SpaceCloud, Yanolja, Kakao) with features for duplicate booking prevention, revenue tracking, customer management, and automated messaging through iCalendar integration.-
Glama MCP Gateway
Add one secure layer between your agents and this server.