See your salon's free slots, appointments, stylists, services, clients, quotes and payments.
Scored across 14 tools
Most tools have clearly distinct purposes, and the descriptions use explicit 'Not for' clauses to separate overlapping areas such as free slots vs closures, appointments vs calendar events, and single-entity gets vs lists. Minor ambiguity remains among open_hairdora, show_salon_overview and get_salon, and among tools that can surface upcoming appointments, but descriptions largely resolve these.
The set predominantly follows a lower_snake_case verb_noun pattern (get_appointment, list_clients, list_salon_availability), which is easy to predict. Two UI-oriented tools, open_hairdora and show_salon_overview, deviate slightly in structure but still match the overall snake_case convention.
Fourteen tools is well-scoped for a salon scheduling domain that covers appointments, clients, salons, services, providers, payments, quotes, availability and calendar events. Each entity gets targeted read tools without excessive proliferation or redundancy.
The surface is entirely read-only: there are no tools to create, update, cancel or manage appointments, clients, payments, quotes or services. For a salon scheduling server, missing booking and mutation operations is a significant gap that prevents agents from completing core scheduling workflows.
Use this when someone asks what services a specific appointment includes, their prices, or the appointment's status. Returns one appointment's client and salon ids, times, status and up to 50 booked services with prices. Not for finding bookings by date.
| Name | Required | Description | Default |
|---|---|---|---|
| appointmentId | Yes | Id of one appointment, as the appointment list returns it (24 lowercase hex characters) |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| appointment | Yes | One booking with up to 50 booked services and their prices; null when not found. Free-text notes, reminders, contact details, organization data and payment data are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: the result is scoped to a single appointment and capped at 50 booked services with prices, which tells the agent what to expect from the payload.
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?
Three tight sentences, each earning its place: usage trigger first, then return contents, then the exclusion. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, rich annotations, and no nested objects, the description covers what it is, when to call it, what it returns (including the 50-service cap), and what it isn't for. Nothing needed to invoke it 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?
With 100% schema description coverage on the single appointmentId parameter, the schema already documents the 24-lowercase-hex format and that it comes from the appointment list. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.
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+resource (get one appointment's details) and enumerates exactly what it returns: client and salon ids, times, status, and up to 50 booked services with prices. It also distinguishes itself from the sibling list_appointments by explicitly excluding date-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear triggering condition ('when someone asks what services a specific appointment includes, their prices, or the appointment's status') and an explicit exclusion ('Not for finding bookings by date'). The only gap is that it doesn't name list_appointments as the alternative tool to use for date-based searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks about one salon client, such as their preferred language or which salon they belong to. Returns the client's name, salon, language and last edit time. Not for the client's email, phone or booking history.
| Name | Required | Description | Default |
|---|---|---|---|
| clientId | Yes | Id of one client, as the client list returns it (24 lowercase hex characters) |
| Name | Required | Description |
|---|---|---|
| client | Yes | Name, salon, language and edit time only; null when not found. Email, phone, address, operator notes, service and colour history, organization data and other profile fields are excluded. |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered by structured data. The description adds genuine value by enumerating the returned fields (name, salon, language, last edit time), which is behavioral context beyond what annotations express. Output schema exists, so full return-value narration isn't required, but the field list is a useful addition.
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?
Three short sentences, zero waste, front-loaded with the trigger condition followed by return-value summary and exclusion. Every sentence 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?
Given a single well-documented parameter, full annotation coverage, and an output schema, the description covers when-to-use, when-not, and what's returned. It could be slightly stronger by naming the specific alternative for the excluded cases (email/phone/booking history), but otherwise nothing an agent needs 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% – the clientId parameter is fully documented in the schema with format and source guidance. The description adds nothing about the parameter, which is acceptable given the baseline-3 rule when schema coverage is high.
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 (get one salon client) and distinguishes from siblings by naming list_clients implicitly and contrast with other get_* tools via the 'one salon client' framing. Explicitly scopes to a single client, unlike the list_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear when-to-use trigger ('when someone asks about one salon client') and an explicit when-NOT ('Not for the client's email, phone or booking history'), routing the agent away from inappropriate alternatives. The negative guidance is unusually specific for this category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks for one salon's opening hours, address, phone, website, timezone or default appointment length. Returns that salon's business settings with up to 14 opening-hour rows, Monday first. Not for free booking slots.
| Name | Required | Description | Default |
|---|---|---|---|
| salonId | Yes | Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters) |
| Name | Required | Description |
|---|---|---|
| salon | Yes | Business settings of the salon; null when not found. Organization ids, payment configuration, credentials, integrations, reminders, staff data and internal metadata are excluded. |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral detail: the result contains up to 14 opening-hour rows ordered Monday first, which helps the agent interpret the payload.
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?
Three short sentences, all front-loaded with the use case first and the exclusion last. No filler and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with full annotation coverage and an existing output schema, the description covers purpose, trigger, exclusion, and return shape — nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and the schema already documents salonId at 100% coverage including the 24-hex-character format. The description's 'one salon's' implies a single-ID lookup but adds no syntax or sourcing detail beyond the schema, so baseline 3 is appropriate.
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?
Names a specific verb+resource (get one salon's business settings) and enumerates the fields returned (hours, address, phone, website, timezone, default appointment length). It reads as clearly distinct from list_salons and get_salon_availability.
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?
Explicitly states the triggering condition ('when someone asks for one salon's opening hours, address, phone...') and an exclusion ('Not for free booking slots'), which routes the agent to get_salon_availability for the adjacent need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks when their hair salon has free appointment slots or the next opening. Returns, per day, how many online-booking slots are open plus the first start and last end time, for the next 14 days that have openings (no client or stylist names). Not for making a booking.
| Name | Required | Description | Default |
|---|---|---|---|
| salonId | Yes | Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters) |
| Name | Required | Description |
|---|---|---|
| days | Yes | One row per day with open online-booking slots inside the salon's booking window, in date order. Slot counts and times only; who holds a booked time is never exposed. |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, so the bar is lower. The description adds genuine context beyond them: the 14-day window, the per-day aggregation, and the privacy scoping ('no client or stylist names'), which tells the agent what is deliberately omitted.
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?
Three short sentences, front-loaded with the usage trigger, then the return shape, then the boundary. Every sentence earns its place with no redundancy.
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 values needn't be spelled out, and the description nonetheless summarizes the aggregation and the 14-day cap. Combined with full annotation coverage, an agent has enough to invoke it correctly.
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?
Only one parameter (salonId) and schema description coverage is 100%, so the schema already documents the id format and constraint. The description adds no parameter-level meaning, making the baseline 3 correct.
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 ('free appointment slots', 'next opening') and clearly distinguishes itself from siblings like get_appointment and list_appointments by describing what it returns per day. An agent can tell this is an availability lookup, not an appointment retrieval.
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?
Explicitly says when to use it ('when someone asks when their hair salon has free appointment slots or the next opening') and adds a boundary ('Not for making a booking'). No sibling alternative is named for the booking case, but the exclusion is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks how many appointments are booked on a day or in a period, how many were canceled or no-shows, or when a client is booked. Returns appointments across all the user's salons, or just one, with id, client and salon ids, times and status for any date window, latest first, up to 100. Not for the services inside an appointment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of appointments to return (default 20, maximum 100) | |
| endTime | No | Only appointments ending before this ISO 8601 time | |
| salonId | No | Only appointments at this salon, by an id from the user's salon list; every salon when absent | |
| clientId | No | Only appointments of this client, by an id from the client list | |
| startTime | No | Only appointments starting at or after this ISO 8601 time |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| hasMore | Yes | |
| appointments | Yes | Bookings, latest start first. Free-text notes, reminders, contact details, organization data and payment details are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive safety profile. The description adds behavior beyond that: results come latest-first and are capped at 100, and the tool spans all of the user's salons unless scoped. It does not discuss pagination beyond the cap.
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?
Two dense sentences, front-loaded with the usage conditions, followed by return shape and the exclusion. Every clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still conveys filters, scope, ordering and the cap. Combined with complete parameter coverage and annotations, an agent has everything needed to call it correctly.
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 all five parameters are already documented. The description adds only marginal parameter meaning (date-window filtering, all-salon default, 100 cap, latest-first ordering); the baseline 3 is appropriate when the schema does the heavy lifting.
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?
Names a specific verb and resource (list salon appointments), and states scope precisely: across all the user's salons or just one, with id, client/salon ids, times and status. The closing 'Not for the services inside an appointment' draws a boundary that separates it from appointment-detail siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use triggers: counting appointments in a day or period, canceled/no-show counts, or when a client is booked. It also states one exclusion (services inside an appointment), but does not name the alternative sibling to use instead, so routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks when their salon is closed or has extra opening hours, or when a stylist or chair is blocked for holidays, vacations, sick days, training or meetings. Returns blocks and extra openings with salon, type, scope, effect, all-day flag and times for all salons unless one is given, earliest first (no titles or notes). Not for client appointments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of calendar events to return (default 20, maximum 100) | |
| endTime | No | Only events ending before this ISO 8601 time | |
| salonId | No | Only blocks for this salon, by an id from the user's salon list; every salon when absent | |
| startTime | No | Only events starting at or after this ISO 8601 time |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| events | Yes | Closures, days off and extra openings, earliest first. Free-text titles and notes, chair ids, staff ids, organization data and private reasons are excluded. |
| hasMore | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, idempotent, non-destructive profile, so the description's main added value is the return-shape disclosure: blocks and extra openings with salon, type, scope, effect, all-day flag and times, ordered earliest first, excluding titles/notes. It also states the default scope (all salons unless one is given). This is meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the use case and ending with the exclusion. The second sentence is dense but every clause (return fields, ordering, exclusion of titles/notes) carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with an output schema, a rich annotation set, and 100% schema coverage, the description covers triggers, scope, ordering and exclusions. Nothing an agent needs to select or invoke it 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 all four parameters are documented in the schema, and the description largely repeats the salon-scoping idea already present in salonId. It does add ordering semantics ('earliest first') that the schema does not express, but adds no new syntax or format detail for the parameters themselves.
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 gives a specific verb (list) and resource (closures, days off, blocked time) and explicitly distinguishes the output from client appointments. An agent can identify this tool's domain from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It opens with explicit trigger conditions ('when someone asks when their salon is closed or has extra opening hours, or when a stylist or chair is blocked...') and closes with a clear exclusion ('Not for client appointments'), routing the agent away from the appointment siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks who their clients are, or needs a client id to look up that person's appointments, payments or quotes. Returns up to 100 clients (20 by default) across all the user's salons, or just one, with id, name, salon and last edit time, in no particular order and without a name search. Not for a client's email, phone or notes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of clients to return (default 20, maximum 100) | |
| salonId | No | Only clients of this salon, by an id from the user's salon list; every salon when absent |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| clients | Yes | Clients with the ids needed to look up their bookings, payments and quotes. Email, phone, address, operator notes, service and colour history, organization data and other profile fields are excluded. |
| hasMore | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds genuine behavior: the 20/100 result cap, cross-salon scope, unordered results, and no name-search capability — none of which appear in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences ordered by importance: trigger, return shape/caps, then exclusions. Every clause carries usable information and nothing is redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is optional, yet the description still summarizes the payload, defaults, and scope. Combined with the annotations covering safety, an agent has everything needed to call this correctly.
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 both parameters (limit, salonId) are already documented, including the 20 default / 100 max and the salon scoping semantics. The description restates these without adding format or edge-case detail beyond the schema, so the baseline 3 applies.
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 names a specific verb and resource ('who their clients are'), states the scope (all salons or one), the fields returned (id, name, salon, last edit time), and the cap (100 max, 20 default). It also implicitly distinguishes itself from get_client by noting it returns a list without a name search, so an agent can route correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('when someone asks who their clients are, or needs a client id to look up that person's appointments, payments or quotes') and an explicit exclusion ('Not for a client's email, phone or notes'). It also flags the absence of name search, steering the agent elsewhere for that case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what payments their salon took, whether a client paid, or how much came in over a period. Returns payment records with id, client and salon ids, date, amount, currency and status for any date window and all salons unless one is given, newest first, up to 100 (no card details). Not for charging or refunding a client.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of payments to return (default 20, maximum 100) | |
| endTime | No | Only payments ending before this ISO 8601 time | |
| salonId | No | Only payments at this salon, by an id from the user's salon list; every salon when absent | |
| clientId | No | Only payments from this client, by an id from the client list | |
| startTime | No | Only payments starting at or after this ISO 8601 time |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| hasMore | Yes | |
| payments | Yes | Payment records, newest first; this tool cannot charge, refund or move funds. Cardholder data, processor and customer ids, credentials, errors, discounts, staff commission splits, operator notes and organization data are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds real value beyond them: results are 'newest first', capped at 100, scoped to all salons unless one is given, and notably exclude card details — a meaningful data-sensitivity disclosure. It stops short of describing pagination beyond the limit cap.
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 the triggering question, then the returned shape, scope, ordering, cap and exclusion in a single dense passage. Every clause carries information — no filler, no restatement of the title.
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 field-by-field return documentation is not strictly required, yet the description still names the key fields, which helps selection. Combined with the scope defaults, ordering, cap and card-detail exclusion, an agent has enough to call this correctly; only pagination/truncation behavior past the 100 cap is left unaddressed.
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 each of the five parameters (limit, endTime, salonId, clientId, startTime) is already documented with defaults, ISO 8601 format and id patterns. The description only restates the date window, salon scoping and the 100 cap, adding no format, boundary, or default nuance the schema does not already carry.
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 (list) and resource (salon payments) and immediately enumerates what the returned records contain: id, client and salon ids, date, amount, currency, status. It also draws an explicit boundary ('Not for charging or refunding a client'), so an agent can separate this read tool from payment-mutation intents without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering situations: 'when someone asks what payments their salon took, whether a client paid, or how much came in over a period', and an explicit exclusion for charging/refunding. It does not name an alternative sibling (e.g. list_appointments) for adjacent questions, but no sibling overlaps on payment data, so the routing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which stylists or hairdressers work at their salon or can be booked. Returns up to 100 hairdresser display names from the organization that owns the salon (no contact details or schedules). Not for stylists' days off.
| Name | Required | Description | Default |
|---|---|---|---|
| salonId | Yes | Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters) |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| status | Yes | |
| hasMore | Yes | |
| providers | Yes | Display names of organization members with the hairdresser role; roles are organization-wide, not per salon. Staff ids, contact details, avatar URLs, role records, schedules and organization data are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context. It does: a hard cap of 100 results, the org-level scope, and an explicit statement that contact details and schedules are NOT returned. That negative disclosure is genuinely useful for planning follow-up calls.
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?
Three short sentences: trigger first, return shape and scope second, exclusion last. Every sentence carries distinct information and nothing is repeated from the name or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full annotation coverage and an output schema, this is complete: the agent knows when to call it, what it gets back, what it won't get back, and the result cap. No further description is needed to invoke it correctly.
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% for the single salonId parameter, so the baseline is 3. The description adds only indirect value by tying the result set to the organization that owns the salon, implying salonId is the resolution key, but supplies no format or validation detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('which stylists or hairdressers work at their salon or can be booked') and pins down the return set: up to 100 hairdresser display names scoped to the salon's owning organization. An agent can distinguish this from list_salons, list_services, or get_salon_availability without opening the schema.
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 an explicit trigger ('when someone asks which stylists or hairdressers work at their salon') and an explicit exclusion ('Not for stylists' days off'), which implicitly routes to get_salon_availability. It does not name the alternative tool directly, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks about price quotes given to salon clients, such as which are pending, approved or rejected. Returns quotes with id, client and salon ids, status and date for all salons unless one is given, newest first, up to 100; the status filter applies within that page. Not for quote amounts or line items.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of quotes to return (default 20, maximum 100) | |
| status | No | Only quotes with this status: DRAFT, PENDING, REJECTED or APPROVED. Applied within the fetched page of newest quotes | |
| endTime | No | Only quotes ending before this ISO 8601 time | |
| salonId | No | Only quotes from this salon, by an id from the user's salon list; every salon when absent | |
| clientId | No | Only quotes for this client, by an id from the client list | |
| startTime | No | Only quotes starting at or after this ISO 8601 time |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| quotes | Yes | Quotes, newest first. Free-text notes, quoted line details and amounts, discounts, contact details and organization data are excluded. |
| hasMore | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent/destructive hints already covering the safety profile, the description adds genuinely useful behavior: results span all salons unless one is given, ordering is newest-first, the cap is 100, and crucially the status filter applies only within the fetched page rather than globally. That page-scoped filter caveat is a real surprise-preventing detail, though nothing is said about what happens when more than 100 quotes match.
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?
Three sentences, front-loaded with the trigger condition before the mechanical details, and no filler. Slightly dense in the middle sentence, where return fields, default scoping, ordering, and page-size limit are compressed into one clause-heavy run.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The return shape is already covered by the output schema, and the description still summarizes the key fields, so an agent knows what it is getting. Ordering, scoping and pagination interactions are addressed; the only loose end is behavior at the 100-item boundary (truncation vs. pagination).
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 and every parameter already carries its own explanation, including the page-scoped status note and the 'every salon when absent' default. The description restates salon scoping and the page-scoped status filter without adding format, time-window, or interaction semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (listing price quotes given to salon clients) plus the concrete states it surfaces (pending, approved, rejected). It also explicitly disclaims adjacent scopes ('Not for quote amounts or line items'), so an agent can separate it from detail-oriented quote tools despite no direct quote sibling existing.
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?
Opens with an explicit trigger ('Use this when someone asks about price quotes given to salon clients...') and gives a negative boundary ('Not for quote amounts or line items'). It stops short of naming the alternative tool an agent should use when it does need amounts or line items, so the exclusion has no destination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which hair salons they run in HairDora, or a salon's id is needed. Returns up to 100 salons with id, name, currency, default language and last edit time. Not for a salon's address, phone or opening hours.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| salons | Yes | Salons in the signed-in organization. Contact, address, payment, organization and configuration fields are excluded. |
| hasMore | Yes | True when the organization has more than 100 salons |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world. The description adds a real behavioral constraint the annotations cannot convey: results are capped at up to 100 salons, and it enumerates the returned fields. It does not address what happens when more than 100 exist (truncation/pagination), leaving one gap.
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?
Two tight sentences: the trigger and the exclusion are front-loaded, and the payload description follows. No filler or redundancy.
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, the description need not detail return structure, yet it still summarizes the key fields and the 100-salon cap. Combined with annotations covering the safety profile, an agent has everything needed to select and call it.
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?
The tool takes zero parameters, so per the baseline rule a 4 applies. There is no parameter semantics for the description to add, and it correctly does not invent any.
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 and resource (list salons) and explicitly names the returned fields (id, name, currency, default language, last edit time). It also carves out a boundary against sibling tools: "Not for a salon's address, phone or opening hours," which distinguishes it from get_salon/show_salon_overview.
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 clear trigger conditions: when a user asks which salons they run, or when a salon id is needed for a follow-up call. It also states what the tool is not for. It stops short of naming the alternative tool (get_salon) for detail lookups, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what their salon charges for a cut, colour, blow-dry or other service, or what services it offers. Returns services with id, name, price and salon for all their salons unless one is given, 50 by default and up to 100. Not for what a particular client had done.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of services to return (default 50, maximum 100) | |
| salonId | No | Only services of this salon, by an id from the user's salon list; every salon when absent |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| hasMore | Yes | |
| services | Yes | Services the salon offers, with prices. Internal metadata and organization data are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, so the bar is lower; the description adds real behavioral context — the default page size of 50, the 100 cap, and that all salons are returned unless one is specified. It doesn't mention pagination continuation behavior, but that is minor.
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?
Three short sentences, front-loaded with the use case, then the return shape and defaults, then the exclusion. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, yet the description still sketches the fields and paging defaults. For a two-param read tool with full annotations, nothing an agent needs to invoke it 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 description coverage is 100%, so both parameters are already documented in the schema. The description restates the 50-default/100-max limit and the all-salons-unless-given behavior, adding little beyond what the schema provides.
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 ('list' services with 'price') and enumerates the fields returned (id, name, price, salon). It also names the scope boundary against siblings by excluding 'what a particular client had done,' separating it from appointment/client history tools.
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 a clear situational trigger ('when someone asks what their salon charges for a cut, colour, blow-dry or other service') plus one exclusion. It does not name the alternative tool an agent should reach for instead, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to open HairDora and browse their salons, upcoming appointment previews, service prices and booking availability in an interactive sidebar. Returns up to 100 salons to start from (no client names, contact details or private notes). Not for booking, cancelling or charging for appointments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: a result cap of 100 salons and an explicit data-exposure boundary (no client names, contact details or private notes), which is exactly the kind of disclosure an agent cannot infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the trigger condition, then the return cap, then the exclusion. Every sentence carries distinct information with no repetition of the name or title.
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 structure need not be described, and the description still supplies the salient result-limit and privacy constraints. For a zero-parameter launcher tool with full annotation coverage, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly avoids inventing argument behavior that the empty schema does not support.
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 action (open HairDora), the resource surface (salons, upcoming appointment previews, service prices, booking availability) and the delivery form (interactive sidebar). It is clearly distinguishable from siblings like list_salons or show_salon_overview, which return data rather than launching a UI surface.
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 a clear trigger ('when someone wants to open HairDora and browse...') and an explicit exclusion ('Not for booking, cancelling or charging for appointments'). It stops short of naming which sibling to use instead for those excluded actions, so it is strong but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants a quick overview or dashboard of one hair salon. Returns an overview card with the salon's details, a client count, the next 8 upcoming appointments with time, status and number of services, and up to 12 services with prices (no client names or contact details). Not for one specific booking.
| Name | Required | Description | Default |
|---|---|---|---|
| salonId | Yes | Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters) |
| Name | Required | Description |
|---|---|---|
| salon | Yes | Salon metadata; null when not found. The overview excludes client names, contact details, client and appointment ids, notes, organization data, staff ids, payment data and service history. |
| services | Yes | |
| clientCount | Yes | |
| appointments | Yes | The next upcoming appointments, earliest first |
| serviceCount | Yes | |
| appointmentCount | Yes | |
| clientCountIsLowerBound | Yes | |
| serviceCountIsLowerBound | Yes | |
| appointmentCountIsLowerBound | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious context: the payload shape, the caps (8 appointments, 12 services), and a privacy boundary (no client names or contact details). It does not mention pagination or error behavior, but that is minor here.
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?
Two sentences, zero padding: the usage condition is front-loaded and the second sentence is a tight, itemized inventory of the return payload. Every clause carries information.
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 values need not be explained, yet the description still summarizes the payload and its privacy limits, making the tool fully callable and interpretable. Nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single salonId parameter already documents its 24-hex format and provenance ('as the salon list returns it'). The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.
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 and resource ('show... overview... of one hair salon') and enumerates exactly what the aggregate contains (details, client count, next 8 appointments, up to 12 services). This clearly separates it from the singular-record siblings like get_appointment and get_client.
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 an explicit when-to-use trigger ('when someone wants a quick overview or dashboard') and an explicit exclusion ('Not for one specific booking'), which routes the agent away from get_appointment. It does not name the neighboring alternatives like get_salon or list_appointments by name, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
open_hairdoraget_appointment2 fields changedInput schema / properties / appointmentId / descriptionPrevious value: -"Appointment id returned by list_appointments (24 lowercase hex characters)"New value: +"Id of one appointment, as the appointment list returns it (24 lowercase hex characters)"Output schema / properties / appointment / descriptionAdded value: +"One booking with up to 50 booked services and their prices; null when not found. Free-text notes, reminders, contact details, organization data and payment data are excluded."get_client2 fields changedInput schema / properties / clientId / descriptionPrevious value: -"Client id returned by list_clients (24 lowercase hex characters)"New value: +"Id of one client, as the client list returns it (24 lowercase hex characters)"Output schema / properties / client / descriptionAdded value: +"Name, salon, language and edit time only; null when not found. Email, phone, address, operator notes, service and colour history, organization data and other profile fields are excluded."get_salon3 fields changedInput schema / properties / salonId / descriptionPrevious value: -"Salon id returned by list_salons (24 lowercase hex characters)"New value: +"Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters)"Output schema / properties / salon / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "appointmentDuration": {
- "anyOf": [
- {
- "exclusiveMinimum": 0,
- "maximum": 1440,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "city": {
- "anyOf": [
- {
- "maxLength": 200,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "countryCode": {
- "anyOf": [
- {
- "pattern": "^[A-Z]{2}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "currency": {
- "anyOf": [
- {
- "pattern": "^[A-Z]{3}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "defaultLocale": {
- "anyOf": [
- {
- "maxLength": 16,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "firstDayOfTheWeek": {
- "anyOf": [
- {
- "enum": [
- "Monday",
- "Tuesday",
- "Wednesday",
- "Thursday",
- "Friday",
- "Saturday",
- "Sunday"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- "name": {
- "maxLength": 200,
- "type": "string"
- },
- "openingHours": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "close": {
- "anyOf": [
- {
- "pattern": "^\\d{1,2}:\\d{2}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "day": {
- "anyOf": [
- {
- "enum": [
- "Monday",
- "Tuesday",
- "Wednesday",
- "Thursday",
- "Friday",
- "Saturday",
- "Sunday"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "open": {
- "anyOf": [
- {
- "pattern": "^\\d{1,2}:\\d{2}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "day",
- "open",
- "close"
- ],
- "type": "object"
- },
- "maxItems": 14,
- "type": "array"
- },
- "openingHoursTruncated": {
- "type": "boolean"
- },
- "phone": {
- "anyOf": [
- {
- "maxLength": 32,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "postalCode": {
- "anyOf": [
- {
- "maxLength": 32,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "state": {
- "anyOf": [
- {
- "maxLength": 200,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "street": {
- "anyOf": [
- {
- "maxLength": 200,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "timezone": {
- "anyOf": [
- {
- "maxLength": 64,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "website": {
- "anyOf": [
- {
- "maxLength": 2048,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "id",
- "name",
- "currency",
- "defaultLocale",
- "timezone",
- "countryCode",
- "firstDayOfTheWeek",
- "appointmentDuration",
- "phone",
- "street",
- "city",
- "state",
- "postalCode",
- "website",
- "openingHours",
- "openingHoursTruncated"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "appointmentDuration": {
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "maximum": 1440,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Default appointment length in minutes"
+ },
+ "city": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "countryCode": {
+ "anyOf": [
+ {
+ "pattern": "^[A-Z]{2}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "currency": {
+ "anyOf": [
+ {
+ "pattern": "^[A-Z]{3}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "defaultLocale": {
+ "anyOf": [
+ {
+ "maxLength": 16,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "firstDayOfTheWeek": {
+ "anyOf": [
+ {
+ "enum": [
+ "Monday",
+ "Tuesday",
+ "Wednesday",
+ "Thursday",
+ "Friday",
+ "Saturday",
+ "Sunday"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ "name": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "openingHours": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "close": {
+ "anyOf": [
+ {
+ "pattern": "^\\d{1,2}:\\d{2}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "day": {
+ "anyOf": [
+ {
+ "enum": [
+ "Monday",
+ "Tuesday",
+ "Wednesday",
+ "Thursday",
+ "Friday",
+ "Saturday",
+ "Sunday"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "open": {
+ "anyOf": [
+ {
+ "pattern": "^\\d{1,2}:\\d{2}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "day",
+ "open",
+ "close"
+ ],
+ "type": "object"
+ },
+ "maxItems": 14,
+ "type": "array"
+ },
+ "openingHoursTruncated": {
+ "description": "True when the salon has more than 14 opening-hour rows",
+ "type": "boolean"
+ },
+ "phone": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postalCode": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "state": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "street": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "website": {
+ "anyOf": [
+ {
+ "maxLength": 2048,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "currency",
+ "defaultLocale",
+ "timezone",
+ "countryCode",
+ "firstDayOfTheWeek",
+ "appointmentDuration",
+ "phone",
+ "street",
+ "city",
+ "state",
+ "postalCode",
+ "website",
+ "openingHours",
+ "openingHoursTruncated"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / salon / descriptionAdded value: +"Business settings of the salon; null when not found. Organization ids, payment configuration, credentials, integrations, reminders, staff data and internal metadata are excluded."get_salon_availability4 fields changedInput schema / properties / salonId / descriptionPrevious value: -"Salon id returned by list_salons (24 lowercase hex characters)"New value: +"Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters)"Output schema / properties / days / descriptionAdded value: +"One row per day with open online-booking slots inside the salon's booking window, in date order. Slot counts and times only; who holds a booked time is never exposed."Output schema / properties / days / items / properties / firstSlot / descriptionAdded value: +"Start time of the first open slot that day"Output schema / properties / days / items / properties / lastSlot / descriptionAdded value: +"End time of the last open slot that day"list_appointments3 fields changedInput schema / properties / clientId / descriptionPrevious value: -"Filter by a client id returned by list_clients"New value: +"Only appointments of this client, by an id from the client list"Input schema / properties / salonId / descriptionPrevious value: -"Filter by a salon id returned by list_salons"New value: +"Only appointments at this salon, by an id from the user's salon list; every salon when absent"Output schema / properties / appointments / descriptionAdded value: +"Bookings, latest start first. Free-text notes, reminders, contact details, organization data and payment details are excluded."list_calendar_events4 fields changedInput schema / properties / salonId / descriptionPrevious value: -"Filter by a salon id returned by list_salons"New value: +"Only blocks for this salon, by an id from the user's salon list; every salon when absent"Output schema / properties / events / descriptionAdded value: +"Closures, days off and extra openings, earliest first. Free-text titles and notes, chair ids, staff ids, organization data and private reasons are excluded."Output schema / properties / events / items / properties / effect / descriptionAdded value: +"BLOCK removes bookable time; OPEN adds hours on a normally closed time"Output schema / properties / events / items / properties / scope / descriptionAdded value: +"SALON: the whole salon; PROVIDER: one or more stylists; CHAIR: one chair"list_clients2 fields changedInput schema / properties / salonId / descriptionPrevious value: -"Filter by a salon id returned by list_salons"New value: +"Only clients of this salon, by an id from the user's salon list; every salon when absent"Output schema / properties / clients / descriptionAdded value: +"Clients with the ids needed to look up their bookings, payments and quotes. Email, phone, address, operator notes, service and colour history, organization data and other profile fields are excluded."list_payments3 fields changedInput schema / properties / clientId / descriptionPrevious value: -"Filter by a client id returned by list_clients"New value: +"Only payments from this client, by an id from the client list"Input schema / properties / salonId / descriptionPrevious value: -"Filter by a salon id returned by list_salons"New value: +"Only payments at this salon, by an id from the user's salon list; every salon when absent"Output schema / properties / payments / descriptionAdded value: +"Payment records, newest first; this tool cannot charge, refund or move funds. Cardholder data, processor and customer ids, credentials, errors, discounts, staff commission splits, operator notes and organization data are excluded."list_providers2 fields changedInput schema / properties / salonId / descriptionPrevious value: -"Salon id returned by list_salons (24 lowercase hex characters)"New value: +"Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters)"Output schema / properties / providers / descriptionAdded value: +"Display names of organization members with the hairdresser role; roles are organization-wide, not per salon. Staff ids, contact details, avatar URLs, role records, schedules and organization data are excluded."list_quotes4 fields changedInput schema / properties / clientId / descriptionPrevious value: -"Filter by a client id returned by list_clients"New value: +"Only quotes for this client, by an id from the client list"Input schema / properties / salonId / descriptionPrevious value: -"Filter by a salon id returned by list_salons"New value: +"Only quotes from this salon, by an id from the user's salon list; every salon when absent"Input schema / properties / status / descriptionPrevious value: -"Filter by quote status (applied after fetching)"New value: +"Only quotes with this status: DRAFT, PENDING, REJECTED or APPROVED. Applied within the fetched page of newest quotes"Output schema / properties / quotes / descriptionAdded value: +"Quotes, newest first. Free-text notes, quoted line details and amounts, discounts, contact details and organization data are excluded."list_salons2 fields changedOutput schema / properties / hasMore / descriptionAdded value: +"True when the organization has more than 100 salons"Output schema / properties / salons / descriptionAdded value: +"Salons in the signed-in organization. Contact, address, payment, organization and configuration fields are excluded."list_services3 fields changedInput schema / properties / salonId / descriptionPrevious value: -"Filter by a salon id returned by list_salons"New value: +"Only services of this salon, by an id from the user's salon list; every salon when absent"Output schema / properties / services / descriptionAdded value: +"Services the salon offers, with prices. Internal metadata and organization data are excluded."Output schema / properties / services / items / properties / price / descriptionAdded value: +"Price in the salon's currency"show_salon_overview3 fields changedInput schema / properties / salonId / descriptionPrevious value: -"HairDora salon id to render"New value: +"Id of one of the user's salons, as the salon list returns it (24 lowercase hex characters)"Output schema / properties / appointments / descriptionAdded value: +"The next upcoming appointments, earliest first"Output schema / properties / salon / descriptionAdded value: +"Salon metadata; null when not found. The overview excludes client names, contact details, client and appointment ids, notes, organization data, staff ids, payment data and service history."get_appointmentget_clientget_salonget_salon_availabilitylist_appointmentslist_calendar_eventslist_clientslist_paymentslist_providerslist_quoteslist_salonslist_servicesshow_salon_overviewSalon and clinic appointments: check availability, hold slots, take deposits, move and cancel.
See your clinic's free slots, doctors, rooms, service prices and how busy each day is.
See your vet clinic's free slots, vets, service prices, payments and how busy each day is.
Scheduling, availability, clients, billing and CRM for appointment-based services.
Add one secure layer between your agents and this server.