F
licenseNot graded
qualityD
maintenanceEnables users to query real-time reservation availability for Naver Booking places in Korea, including beauty salons, restaurants, and other categories.
-
Timeplex K-Beauty Booking
by ai.timeplex
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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
5 toolsget_shop_servicesARead-onlyIdempotentInspect
Get the available services, prices, durations, and bookable staff or resources for a specific Korean beauty or wellness shop. Use this after finding a shop when service details, prices, durations, staff, or resources are needed before checking appointment availability. Pass lang to receive the content translated into the customer's language.
ParametersJSON Schema
| 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
ParametersJSON 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.7/5.0
Behavior4/5
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 covered. The description adds meaningful context beyond the annotations by stating it returns services, prices, durations, and bookable staff/resources, and that passing 'lang' translates content into the customer's language. This adds functional behavior not present in the structured metadata, though it doesn't mention rate limits or pagination, which is minor for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences and front-loads the core purpose. The first sentence states the primary function, and the second sentence covers usage timing and translation behavior. There is no superfluous content, and every statement earns its place. It is concise yet informative.
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?
Given the tool's low complexity (2 params, 1 required), the presence of an output schema, and annotations covering safety, the description is complete. It explains what the tool returns, when to use it in the workflow, and how to request translation. Nothing an agent needs to correctly invoke it is missing. The sibling distinction and usage guidance are fully covered.
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 description coverage is 100%, so both 'slug' and 'lang' are already documented in the schema. The description goes beyond the schema by explaining that 'lang' translates the returned content, adding a behavioral nuance not in the schema's parameter description. For 'slug,' the schema already references it as returned by search_shops, and the description doesn't need to add more. This is a slight enhancement over the baseline of 3 for full coverage.
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 opens with a specific verb 'Get' and names the exact resource ('available services, prices, durations, and bookable staff or resources') for a specific shop. It differentiates itself from siblings by placing itself between finding a shop and checking availability, which maps directly to search_shops and search_availability. This is unambiguous and distinguishes it from the other tools without needing their schemas.
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?
The description explicitly states when to use the tool: 'Use this after finding a shop when service details, prices, durations, staff, or resources are needed before checking appointment availability.' This provides a clear temporal sequence and condition, implicitly contrasting with search_availability (for checking availability) and search_shops (for finding the shop). It also mentions the optional 'lang' parameter for translation, which further guides correct invocation.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Customer language (optional) | |
| venue_name | Yes | Name of the shop the customer wants to book |
Output Schema
ParametersJSON 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
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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 real-time appointment availability and available time slots for a Korean beauty or wellness shop. Use this tool when a user asks whether a specific date or time is available, wants to find an available appointment slot, or asks for alternatives when a preferred time is unavailable. Returns available times and nearby alternatives when the requested time is unavailable. All times are in Korea Standard Time (KST).
ParametersJSON Schema
| 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 people. |
Output Schema
ParametersJSON 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.1/5.0
Behavior4/5
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 covered. The description adds genuine behavioral value beyond annotations: results are 'real-time', it 'returns available times and nearby alternatives when the requested time is unavailable', and all times are in KST. This context helps the agent set expectations about fallback behavior and timezone handling.
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?
Four sentences, front-loaded with purpose, with each sentence earning its place (purpose, use conditions, fallback behavior, timezone). Minor redundancy: the 'nearby alternatives when a preferred time is unavailable' idea appears in both sentence two and sentence three, but overall it is tight and well-ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and schema coverage is 100%, the description covers the essentials: what the tool returns, when to use it, fallback behavior, and timezone. It is complete enough for correct invocation; slight gaps around alternative granularity are adequately deferred to the output schema.
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 the baseline is 3 and the schema already documents all parameters including the Asia/Seoul date format and the items model with resource_id/qty rules. The description adds only marginal reinforcement via the KST mention and the alternative-finding behavior mapped to the optional time parameter; it does not compensate beyond baseline because no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Check real-time appointment availability and available time slots for a Korean beauty or wellness shop') and clearly defines scope. It naturally distinguishes from siblings: search_shops searches shops, request_booking/start_booking create bookings, and get_booking_status checks existing status, so an agent can route correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use conditions: asking whether a specific date/time is available, finding an available slot, or requesting alternatives when preferred time is unavailable. However, it does not explicitly name sibling alternatives or state when NOT to use this tool, leaving exclusion guidance to inference.
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 Korean beauty and wellness shops by shop name, service type, or location. Use this tool when a user wants to find a beauty salon, hair salon, nail salon, skincare or facial shop, spa, massage shop, or other K-beauty business in Korea, including requests for appointment or booking options. 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 — massage, spa, nail, skincare, facial, waxing, scrub, etc.). 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. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Shop name, service, or natural-language search term (optional). If no shop name matches, it is also interpreted as a service/category search. | |
| location | No | 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. | |
| service_type | No | 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | No | Follow-up guidance for the agent |
| count | Yes | |
| shops | Yes | Matching shops. |
| categories | No | |
| 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. |
| available_service_types | No | business_type values currently registered |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so safety is known. The description goes beyond by detailing the bookable flag semantics, the hair/beauty categorization, the shop_name_not_found response behavior, address inclusion for area questions, and the instruction to use reply_header and match user language. This adds substantial behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical but every sentence carries actionable information. It front-loads the purpose and follows with usage context, behavioral details, and response handling. The structure is logical, though it could be slightly more concise without losing value.
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 search tool with an output schema, the description covers all critical aspects: matching semantics, fallback behavior, bookability implications, error handling, location filtering, and response formatting. Given its complexity (3 optional params, category logic, internationalization), nothing essential is missing. The output schema presumably defines the result structure, so the description doesn't need to repeat it.
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%, but the description enriches parameter understanding: it explains query falls back to service/category search, location matches against address and excludes shops without addresses, and service_type accepts broad and specific categories in multiple languages. These nuances are not present in the schema and materially improve correct usage.
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 opens with a specific verb and resource: 'Search Korean beauty and wellness shops by shop name, service type, or location.' It enumerates the types of businesses covered (salon, spa, nail, etc.) and differentiates itself from booking tools by stating it finds shops and indicates bookability. This clearly distinguishes it from siblings like request_booking or search_availability.
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?
Explicitly says 'Use this tool when a user wants to find a beauty salon, hair salon, nail salon, skincare or facial shop, spa, massage shop, or other K-beauty business in Korea, including requests for appointment or booking options.' It also explains the branching: bookable=true leads to booking through this MCP, bookable=false requires request_booking. It even covers the not-found case with shop_name_not_found and instructs to offer alternatives. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_bookingARead-onlyIdempotentInspect
Create a pre-filled Timeplex booking link (and booking card) for a selected Korean beauty or wellness shop and appointment. Use this after the user has selected or clearly identified a specific shop. A bare category request with no shop chosen and no area or date given ("recommend a scrub shop") is NOT a selection — ask for the area and the booking conditions first instead of calling this tool. This tool does not create or confirm a reservation — it only generates a booking link. Never ask "shall I create a link?". Once a specific shop has been selected or clearly identified, call this tool and include the link in your reply. Date, time and items are all optional — if the customer has not picked them yet, still call it with just the shop; they choose the rest on the booking page. Never withhold the link just to ask for a date, time, or service first. Put link_markdown into your reply as-is — never expose the raw URL. Briefly relay the returned guidance and note to the customer, always in the language the user used, starting with the response's reply_header line. Describe the effect of payment as the time being temporarily secured (Korean: 임시 확보) — never as winning a race or claiming it first (Korean: 선점), and never imply the booking is already complete.
ParametersJSON Schema
| 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. | |
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| 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.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context beyond that: it explicitly states '**This tool does not create or confirm a reservation — it only generates a booking link.**' It also details response handling—including link_markdown usage, relaying guidance in the user's language, and the correct payment wording ('temporarily secured' vs. 'winning a race'). This discloses behavioral traits and response constraints that annotations do not cover, and it does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries instructional weight, covering usage conditions, response formatting, and parameter handling. It is front-loaded with the core purpose and usage condition. Some redundancy exists in repeated 'never' statements, but these serve as explicit prohibitions rather than filler. The structure is clear, though a more condensed version could achieve the same effect with less repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, annotations, and full parameter descriptions, the description is nearly complete for an agent to call the tool correctly. It covers when to call, what it returns (link and guidance), how to present results, and parameter omissions. Minor gaps include handling of invalid slugs or shop not found, but these are typically covered by the output schema and common error handling. The description is robust enough for its complexity.
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?
The schema covers 100% of parameters with descriptive text (e.g., items explanation about designated vs. capacity). The description adds value by clarifying when to omit optional parameters ('if the customer has not picked them yet, still call it with just the shop') and reinforcing that slug must come from search_shops. It also reminds that date/time/items are optional and that the customer chooses them on the booking page, which goes beyond the schema's basic descriptions.
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 opens with a specific verb and resource: 'Create a pre-filled Timeplex booking link (and booking card) for a selected Korean beauty or wellness shop and appointment.' It clearly distinguishes itself from siblings by stating it only generates a link and does not create/confirm a reservation, which separates it from request_booking. The 'selected shop' condition differentiates it from search_shops and search_availability.
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?
The description gives explicit when-to-use and when-not-to-use guidance: 'Use this after the user has selected or clearly identified a specific shop' and contrasts with a bare category request that 'is NOT a selection — ask for the area and the booking conditions first.' It also instructs to never ask for permission, never withhold the link for missing date/time, and always call with just the shop if needed. This directly addresses alternative actions and conditions.
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. Dates show when Glama detected each change.
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
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
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.
- HeyYumiOAuthai.heyyumi
Ground your AI in verified Korean venue data: search & book across Seoul, Gyeonggi, Busan, Jeju.
Related MCP Servers
- 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.235-
- 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.-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.5/5.0
Disambiguation5/5
Each tool targets a distinct step in the booking workflow: searching shops, retrieving services, checking availability, initiating a booking, and handling manual requests for non-bookable shops. Their purposes and usage conditions are clearly separated with specific guidance on when to use each, eliminating ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: get_shop_services, request_booking, search_availability, search_shops, start_booking. The verbs (get, request, search, start) and nouns (shop_services, booking, availability, shops) are all lowercase and underscore-separated, providing a predictable and readable naming scheme.
Tool Count5/5
With exactly 5 tools, the server is well-scoped for its purpose. It covers the essential phases of finding a shop, inspecting services, checking availability, and initiating bookings, without unnecessary expansion. This count is typical for a focused domain-specific MCP and each tool earns its place.
Completeness4/5
The tool set covers the primary booking flow comprehensively: search_shops, get_shop_services, search_availability, and start_booking handle the standard online-booking path, while request_booking covers shops that require manual concierge intervention. Minor gaps exist (e.g., no tool for canceling or modifying bookings), but since start_booking only generates a booking link and actual reservation management happens on the booking page, the surface is reasonably complete for its stated purpose.