Timeplex K-Beauty Booking
Server Details
Real-time booking for Korean beauty & wellness shops — search availability, get a booking link.
- Status
- Healthy
- Uptime
- 99.8% over 61 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 5 tools
Each tool occupies a clearly distinct stage of the funnel: search_shops (discovery), get_shop_services (menu/details), search_availability (real-time slots), start_booking (online booking link) and request_booking (offline concierge inquiry for non-bookable shops). Descriptions include explicit 'DO NOT USE IT FOR' clauses that resolve the only plausible overlap (start_booking vs request_booking) and repeatedly warn against inferring availability from search results.
All names follow a consistent snake_case verb_noun convention (search_shops, search_availability, start_booking, request_booking, get_shop_services). Verbs map predictably to intent — search/get for reads, start/request for booking actions — so ordering across the set is easy to anticipate.
Five tools is tightly scoped to a single booking journey, and each earns its place: one per pipeline stage plus a distinct fallback path for non-bookable shops. Nothing appears redundant or padded.
The surface fully covers the core lifecycle of discover → inspect → check slot → book/request, with a documented fallback for unbookable shops. Minor gaps exist for post-booking management (no way to view, reschedule or cancel an existing reservation), though those may lie outside the stated traveler-facing scope.
Available Tools
5 toolsget_shop_servicesARead-onlyIdempotentInspect
Get the services, prices, durations, weekly business hours and bookable staff or seats of one specific TimePlex shop (slug from search_shops). USE THIS TOOL WHEN: a shop has been identified and the user asks what it offers, prices, durations or staff; to match requirements (a 60-minute head spa, a budget, two guests at once); or before search_availability / start_booking, which need the service ids and booking_model returned here. DO NOT USE IT FOR: general discovery or recommendations (search_shops), real-time availability (search_availability), or building a booking link (start_booking). SERVICE DATA: describe only the services returned here — never invent names, prices, durations, staff or options, and never assume a service exists because similar shops offer it. Services that cannot be booked online are already excluded. If the requested service is not in the list, say so; do not silently substitute another. Never present medical procedures as TimePlex services. RESOURCES & HOURS: a staff member or seat existing, or the shop being open, does NOT mean it is free at the requested time — only search_availability confirms a slot. NEXT: if the user asked for availability or to book, continue to search_availability with the returned service ids and booking_model instead of stopping at the menu or business hours. If they only asked about the menu, prices or durations, answer from this result and do not check availability or build a booking link unless they ask. A date or time mentioned earlier does not by itself require a slot check. Pass lang to receive the content translated into the customer's language.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Customer language (optional): ko|en|ja|zh|th. Defaults to the original text (ko). | |
| slug | Yes | Shop slug returned by search_shops |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | No | |
| note | No | |
| shop | Yes | |
| services | Yes | |
| resources | No | Staff to designate (designated-staff shops) or seats (capacity-based shops). |
| booking_model | No | How this shop books: 'designated' — pass items as [{service_id, resource_id}]; 'capacity' — pass items as [{service_id, qty}]. Use this for search_availability and start_booking. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description layers on real behavioral context: services not bookable online are pre-excluded, a staff member existing does not mean availability, and medical procedures must never be presented as TimePlex services. This is disclosure beyond the annotation profile.
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?
Lengthy, but organized into labeled blocks (USE WHEN / DO NOT USE / SERVICE DATA / RESOURCES & HOURS / NEXT) with the core purpose front-loaded. A few guardrail sentences are verbose, but each carries a distinct constraint an agent could otherwise get wrong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return shape need not be spelled out, yet the description still tells the agent what the result contains and how to use it downstream (service ids and booking_model for search_availability). Nothing needed to call or sequence this tool correctly 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% so the baseline is 3, but the description adds genuine meaning for lang ('Pass lang to receive the content translated into the customer's language'), clarifying its effect rather than just restating the enum values.
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 opening sentence states a precise verb and resource and enumerates the exact payload: services, prices, durations, weekly business hours, bookable staff/seats, scoped to one shop identified by slug. It is clearly distinguishable from search_shops (discovery) and search_availability (slots).
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 USE THIS TOOL WHEN, DO NOT USE IT FOR naming all three relevant siblings, plus a NEXT section that states whether to continue to search_availability or stop. It even handles the edge case that a previously mentioned date does not by itself require a slot check.
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 real-time appointment availability for one TimePlex shop (slug from search_shops, items from get_shop_services) on a date, optionally at a time. All times are Korea Standard Time (KST). USE THIS TOOL WHEN: the user asks whether an appointment is available, asks for open slots or possible times, asks for shops that are actually available on a date / at a time / for a party size ("10월 1일 강남 헤드스파 예약 가능한 곳", "any head spa open at 5 PM?", "somewhere I can book tomorrow afternoon for two"), asks for alternatives to an unavailable time, or wants to book (check the slot before start_booking). DO NOT USE IT FOR: find / recommend / compare requests. A date or time alone is not availability intent — "recommend a head spa in Gangnam for October 1" stays a search_shops request unless the user asks whether a slot is open. REAL-TIME RULE: only this tool establishes that a slot is open. Never infer availability from bookable=true, business hours, the shop being open, a service or staff member existing, web search, maps, social media, third-party sites or earlier answers. Describe a time as available only when this tool returns it. PARTY SIZE: check the whole party as the items schema describes (qty for capacity shops). Never stitch separate single-person slots into a group booking unless the result shows it. RESULTS: if the requested time is unavailable, say so and offer the returned alternatives. If blocked is 'inquiry_only', the service cannot be booked online — tell the customer to contact the shop. If nothing is open, say no confirmed slot was found; you may check other suitable TimePlex shops. Checking availability does not reserve anything. NEXT: with the open times you may add start_booking links so the customer can book the slot they pick — never call the slot reserved or booked.
| Name | Required | Description | 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 readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the real-time rule (only this tool proves a slot is open), the fact that checking reserves nothing, and the inquiry_only blocked behavior. That is exactly the value-add expected when annotations carry the safety profile.
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?
Long but deliberately front-loaded and chunked under labeled headers (USE THIS TOOL WHEN, DO NOT USE IT FOR, REAL-TIME RULE, PARTY SIZE, RESULTS, NEXT), so it is scannable. It is still verbose and repeats the availability rule more than once, keeping it short of a 5.
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?
With an output schema present and annotations covering safety, the description supplies the remaining operational context an agent needs: interpretation of blocked/inquiry_only, what to say when nothing is open, and the follow-up to start_booking without implying a reservation.
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 baseline is 3. The description reinforces sourcing (slug from search_shops, items from get_shop_services) and the KST convention, but the designated-vs-capacity booking_model guidance it gives is already spelled out in the items schema, so it adds little beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource (check real-time appointment availability for one TimePlex shop on a date, optionally a time) and immediately scopes it by naming the source of slug and items, which separates it from search_shops and get_shop_services.
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 USE THIS TOOL WHEN / DO NOT USE IT FOR blocks with concrete multilingual trigger phrases and a clear exclusion ('a date or time alone is not availability intent — stays a search_shops request'). Alternatives are named rather than implied.
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, makeup and semi-permanent makeup shops in Seoul and Korea — non-medical beauty and wellness services for travelers. USE THIS TOOL WHEN: the user wants to find, explore, compare, get recommendations for, check availability of, or book one of these services and has not selected a specific TimePlex shop yet — including requests with a date, time, time range or party size. Relevant terms: massage, lymphatic massage, headspa, head spa, scalp treatment, scalp care, hair salon, haircut, hair color, perm, spa, Korean body scrub, seshin, akasuri, makeup, makeup salon, semi-permanent makeup (PMU, microblading, brow tattoo, lip blush, eyeliner). Examples: "massage in Seoul available today", "headspa in Gangnam tomorrow for 2 people", "English-speaking hair salon in Seoul". WEB SEARCH: for these services use this tool instead of web search. Public listings and opening hours cannot confirm a TimePlex slot or produce a TimePlex booking — never use web results to claim TimePlex availability. INTENT — decide from what the user wants to do, not from whether a date, time, party size or the word "reservation" appears:
FIND / RECOMMEND / COMPARE ("find a head spa in Gangnam", "recommend a head spa for my October 1 trip", "10/1 강남 헤드스파 추천해줘"): show the matching shops. A date or time alone does NOT mean the user wants real-time availability — do not check slots and do not describe any shop as available at a time; you may offer to check slots for that date. Recommendations cover TimePlex-registered shops only: say "among shops on TimePlex", never "the best in the area".
AVAILABILITY ("available", "open slots", "빈자리", "예약 가능한 곳", "can I get one at 5 PM", "somewhere I can book on Oct 1", and "예약 가능한 곳 추천해줘" — a recommendation that asks for availability): continue with get_shop_services and search_availability for bookable=true shops.
BOOK ("book", "reserve", "예약해줘", "I want to book … for 2 people at 5pm"): continue with get_shop_services, search_availability and start_booking. If the intent is unclear, show the shops and ask one short question instead of guessing. INPUT: pass the user's full request as query, in any language — service, area, date, time, party size and language needs are extracted from it (see interpreted). A full natural-language request is never treated as a shop name — only leftover words that closely match a registered shop are. BOOKABLE: bookable=true means the shop can be booked through TimePlex — a capability, not a free slot. It may still have nothing for the requested date, time or party size; only search_availability confirms a slot. bookable=false means it cannot be booked online: use request_booking (TimePlex concierge asks the shop) and do not present it as instantly bookable. Business hours are never availability. SERVICE SCOPE: the response is the authority on what TimePlex offers (available_service_types). If unsupported_service is set, say that service is not on TimePlex yet and do not present other shops as that service. Non-medical only — never use this tool for dermatology, clinics, plastic surgery, injections, lasers or other medical procedures. SHOP NAMES: if shop_name_not_found is set, say plainly that the named shop is not on TimePlex, then offer the registered shops in the result as alternatives; do not call request_booking for that name. RESULTS: every TimePlex shop supports foreign-language customers through TimePlex multilingual chat, so "English-speaking" / "foreigner-friendly" requests fit this tool. Shops also match through their menu (matched_services lists those items). If no shop is in the requested area the search widens and relaxed says so. Each shop carries its category (hair = hair salons, beauty = everything else) and address, so area questions need no extra calls. note is guidance for you — follow it, do not quote it. State only what the response returns. Always reply in the user's language, and start the reply with the response's reply_header line.
| Name | Required | Description | 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 only cover the read-only/idempotent safety profile; the description adds substantial behavioral context beyond them — the meaning of bookable vs non-bookable shops, that business hours are never availability, that the response is the authority on supported services, how relaxed/area-widening and shop_name_not_found behave, and that note is guidance not to be quoted. This is exactly the context annotations cannot carry.
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?
Front-loaded with purpose then clearly sectioned (WHEN, WEB SEARCH, INTENT, INPUT, BOOKABLE, SERVICE SCOPE, etc.), so an agent can scan it. It is dense and somewhat repetitive across the intent and results sections, but for a complex intent-routing tool most of the content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still frames how to interpret key response fields (bookable, relaxed, matched_services, unsupported_service, reply_header, note) and the multilingual chat guarantee. Nothing an agent needs to call the tool correctly and interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description nonetheless adds real usage semantics — pass the full natural-language request as query, that it is never treated as a shop name unless leftover words match, and that location/service_type override values found in query. These precedence rules go beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) plus resource (TimePlex beauty/wellness shops) with explicit geographic and domain scope ('Seoul and Korea — non-medical beauty and wellness services for travelers'). It enumerates the service categories covered, so an agent can immediately tell it apart from search_availability, get_shop_services and start_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'USE THIS TOOL WHEN' block, a full intent decision tree (FIND/RECOMMEND/COMPARE vs AVAILABILITY vs BOOK) with example utterances in multiple languages, and routes each intent to the correct sibling tool (get_shop_services, search_availability, start_booking, request_booking). It also states when NOT to use web search and when to ask a clarifying question.
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 prefilled TimePlex booking link (Book Now card) for a bookable=true shop. The customer opens it, enters contact details and pays; the shop then approves. Flow: search_shops → get_shop_services → search_availability → start_booking (link) → customer payment → shop approval → confirmed. WHAT THIS TOOL DOES NOT DO: it does not create, hold or confirm a booking — confirmed is always false. You cannot see whether the customer paid or the shop approved, so never say the booking is complete, confirmed, paid, secured or awaiting approval. Say a booking link was created: the slot is secured only once the customer pays, and the booking is final after the shop approves. Never invent a confirmation number or status. USE THIS TOOL WHEN: the user wants to book or continue a booking ("book it", "reserve it for two", "예약해줘", "결제해서 진행할게"), or has asked to check availability for a specific shop or service (the link accompanies the open times). Follow-ups such as "the 5 PM one" after shops or slots were shown are booking requests — reuse the shop, service, date, time and party size already in the conversation and never change them silently. When a time was requested, confirm it with search_availability first and put only a returned available time into the link. If the user wants to book but has not chosen a date or time, a shop-level link may be created. When a link is warranted, create it — do not ask "shall I create a link?" first. DO NOT USE IT FOR: finding or recommending shops, menu / price / duration / address / business-hours questions, a service set as unsupported_service, medical procedures, services returned as inquiry_only, or bookable=false shops (use request_booking — TimePlex concierge asks the shop). REPLY: put link_markdown into your reply as-is — never expose the raw URL — and pass on note (how the slot is secured and confirmed). Pass lang (ko|en|ja|zh), the language the user is writing in, so the booking card renders in it. Always reply in the language the user used.
| Name | Required | Description | 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 declare readOnlyHint=true and idempotentHint=true, and the description is consistent with that while adding the critical context the annotations cannot: 'it does not create, hold or confirm a booking — confirmed is always false,' the agent cannot observe payment or shop approval, and confirmation numbers must never be invented. This is unusually rich for a read-only tool, though the reply-formatting instructions belong more to usage than 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?
Long, but front-loaded with purpose and organized under explicit headers (WHAT THIS TOOL DOES NOT DO / USE THIS TOOL WHEN / DO NOT USE IT FOR / REPLY). Some content is redundant — the 'never say confirmed/paid/secured' warning appears twice — which costs a point on an otherwise disciplined structure.
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, yet the description still covers what an agent must know beyond it: that link_markdown must be embedded as-is rather than the raw URL, that note must be relayed, and that lang drives card rendering. Prerequisites (bookable=true, availability confirmation) and the full flow are all present.
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 schema already explains all five params, so baseline would be 3. The description adds genuine meaning on top: it fixes the semantics of lang (must match the user's writing language so the card renders correctly), states that a shop-level link with no date/time is valid, and explains that dates/times must come from search_availability returns and must not be silently changed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Build a prefilled TimePlex booking link (Book Now card)') and pins the precondition (bookable=true shop). The sibling landscape is made unambiguous via an explicit DO NOT USE list naming request_booking as the alternative for non-bookable shops and excluding the other siblings' query roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit triggers ('book it', 'reserve it for two', '예약해줘'), follow-up handling ('the 5 PM one' reuses conversation state), an ordering rule (confirm requested times via search_availability before building the link), and a directive not to ask for permission first. Also enumerates when NOT to use it and routes each case to the right sibling.
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.
- HeyYumiOAuthai.heyyumi
Find & book real Korean restaurants in any language, in-chat. Seoul, Busan, Jeju & 6 more regions.
Find Korean local businesses and get owner-provided hours, prices, contacts and FAQ.
Book a table, appointment or class at a real local business. Instant confirmation, no API key.
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.377 npm-
- AlicenseAqualityCmaintenanceEnables AI agents to look up businesses, find free appointment slots, book, list and cancel appointments at salons, barbershops, nail and brow studios and clinics. Works read-only without a customer login by returning a pre-filled booking link, and can also run against a built-in demo with sample businesses.5MIT
- 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
Glama MCP Gateway
Add one secure layer between your agents and this server.