See your salon's free slots, appointments, stylists, services, clients, quotes and payments.
Scored across 21 tools
Most tools target a distinct resource and action, and descriptions include explicit 'not for' boundaries (e.g. get_appointment vs list_appointments vs show_salon_overview). A few read surfaces overlap conceptually, such as salon listing/getting/overview/open_hairdora and services inside an appointment vs list_services, but the descriptions make selection manageable.
Nearly all tools follow a consistent verb_noun snake_case pattern: book_appointment, cancel_appointment, create_client, get_salon, list_payments, etc. Minor deviations are open_hairdora, which is less action-specific, and show_salon_overview, which uses a three-word verb phrase, but the overall convention is predictable.
At 21 tools the surface is slightly heavy, but the breadth is justified by covering appointments, clients, salons, services, inventory, payments, quotes, providers, calendar events, and a UI entry point. There are no obvious redundant duplicates, though open_hairdora and show_salon_overview could arguably be consolidated.
The core scheduling lifecycle is well covered: book, reschedule, cancel, get, list, availability, plus client create/get/list/update and salon reads. Gaps remain around editing an appointment's services or stylist, service/provider administration, inventory creation, and write operations for payments or quotes, though several are explicitly out of scope.
Use this when someone asks to book a client in at their salon. Returns the new appointment with its time, stylist and services; it takes the salon's usual length, chair and reminders, so the salon's reminder messages go to the client. Not for finding free slots.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | A note for the salon team. | |
| salonId | No | Id of the salon, from list_salons. Leave it out when the user has one salon. | |
| clientId | Yes | Id of the client, from list_clients or create_client. | |
| requestId | Yes | A unique id you choose for this booking, such as a UUID. Calling again with the same requestId returns the first booking instead of booking twice. | |
| startTime | Yes | Start as an ISO 8601 time with the salon's UTC offset, such as 2026-11-20T10:00:00+01:00. | |
| serviceIds | No | Ids of the services booked, from list_services. | |
| providerIds | No | Ids of the stylists who take it, from list_providers. Leave it out when the salon has one stylist or the user is the stylist. | |
| durationMinutes | No | Length in minutes. Leave it out for the salon's usual length. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| appointment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the bar is lower, yet the description still adds real behavior: the booking inherits the salon's usual length, chair and reminders, and reminder messages go to the client. It does not spell out the side effects that make this 'destructive' (slot consumption, notifications to stylist) or reference idempotent replay, so it stops short of full disclosure.
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, front-loaded sentences: trigger first, then return value and inherited defaults, then the exclusion. The only waste is the return-value sentence ('Returns the new appointment with its time, stylist and services'), which duplicates what the output schema already provides.
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 a full output schema, complete parameter descriptions and rich annotations, the description only needs to cover intent, defaults and boundaries, and it does all three. The remaining gap is that it never hints at the destructive/idempotent semantics declared in annotations, which matter for an agent retrying a booking.
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 every parameter including requestId idempotency and the UTC-offset time format is already documented in the schema. The description's line about taking 'the salon's usual length, chair and reminders' explains why durationMinutes and providerIds can be omitted, but this largely restates the schema's own 'leave it out' notes rather than adding new 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 gives a specific verb and resource ('book a client in at their salon' -> creates an appointment) and immediately delimits scope with 'Not for finding free slots', which routes the agent away from get_salon_availability. An agent can distinguish it from reschedule_appointment and the list_* siblings 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?
It states a clear trigger condition ('when someone asks to book a client in at their salon') and one explicit exclusion ('Not for finding free slots'). It does not name the alternative tool (get_salon_availability) or say what to do first, e.g. resolve client/salon ids, so it falls short of full when/when-not/alternatives guidance.
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 to cancel a client's appointment. Returns the appointment as canceled, kept rather than deleted, and whether the salon's cancellation message goes to the client. Not for moving an appointment to another time.
| Name | Required | Description | Default |
|---|---|---|---|
| appointmentId | Yes | Id of the appointment, from list_appointments. | |
| expectedLastEditTime | Yes | The lastEditTime from get_appointment or list_appointments. An appointment changed since then is refused. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| appointment | Yes | |
| clientNotification | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, and the description usefully resolves the resulting ambiguity by stating the appointment is 'kept rather than deleted' — i.e. destructive means state change, not removal. It also discloses that the return indicates whether the salon's cancellation message goes to the client. It does not mention permission requirements or the refusal behavior, though the schema covers the latter.
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 with the use case front-loaded, followed by behavioral facts and then the exclusion. No filler and nothing that repeats the title verbatim.
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 two-parameter mutation with an output schema, full schema coverage, and rich annotations, the description supplies everything an agent needs: purpose, soft-delete semantics, return signal, and the sibling exclusion. No material gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented in the schema, including the concurrency-refusal behavior of expectedLastEditTime. The description adds no parameter-level detail, 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 names a specific verb and resource ('cancel a client's appointment') and immediately distinguishes it from the closest sibling by stating 'Not for moving an appointment to another time,' which rules out reschedule_appointment. An agent can pick this tool without opening either 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 to cancel a client's appointment') and an explicit exclusion for rescheduling. It does not name the alternative tool by name or cover edge cases such as already-canceled appointments, so it falls just 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.
Use this when someone asks to add a new client to a salon. Returns the client's id, name, salon and language; the phone and email given are saved but never returned. Not for changing an existing client.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The client's full name. | |
| No | Email address. | ||
| phone | No | Mobile number, with the country code when known. | |
| salonId | No | Id of the salon, from list_salons. Leave it out when the user has one salon. | |
| language | No | Language for their messages, as a code such as en, it or pt-BR. Defaults to the salon language. | |
| requestId | Yes | A unique id you choose for this client, such as a UUID. Calling again with the same requestId returns the first client instead of adding a second one. |
| Name | Required | Description |
|---|---|---|
| client | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare idempotentHint=true and destructiveHint=true, so the safety profile is partly covered. The description adds genuinely non-obvious behavior: phone and email are persisted but never echoed back, which prevents an agent from re-fetching to verify them. It does not discuss what happens on duplicate names or what destructiveHint means in practice for a create.
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, then return behavior, then exclusion. Nothing is padded and every sentence carries information an agent would otherwise have to guess.
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 full parameter documentation, the remaining description burden is small, and the description covers trigger, return shape, and exclusion. The only gap is ambiguous mutation semantics (destructiveHint=true on a create) that the description leaves for the annotation to imply.
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%, including requestId idempotency and the salonId default, so the schema carries the parameter burden. The description only adds the implication that phone and email may be absent ("given") and does not clarify required versus optional fields or formats.
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 and resource ("add a new client to a salon") and frames it in the caller's own terms ("when someone asks to add a new client"). It also names what it is not ("Not for changing an existing client"), which separates it from update_client among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear trigger condition and an explicit exclusion for the modify case, which is the most likely confusion given siblings update_client and get_client. It does not name update_client by name or mention prerequisites, so it stops just 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.
Use this when someone asks what services a specific appointment includes, their prices, or the appointment's status. Returns one appointment's client, salon and stylist 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the payload shape and the 'up to 50 booked services' cap, which tells the agent results may be truncated. It stops short of describing pagination or behavior when the id is unknown.
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, returned fields second, exclusion last. Nothing is redundant and the most decision-relevant information is front-loaded.
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 schema coverage, an output schema, and clear annotations, the description supplies everything needed to select and call it. Return-value details are a bonus rather than a requirement here.
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 parameter's description already specifies the 24-character lowercase hex format and its origin in the appointment list. The description adds only the framing that it is 'one appointment', so 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 pairs a specific verb and resource ('Returns one appointment's client, salon and stylist ids, times, status and up to 50 booked services') and explicitly contrasts scope with 'findings bookings by date', separating it from list_appointments. An agent can identify the tool 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 a concrete trigger ('when someone asks what services a specific appointment includes, their prices, or the appointment's status') and a negative bound ('Not for finding bookings by date'). The alternative tool is not named explicitly, so routing still requires inferring that the date-based path is list_appointments.
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, when a client is booked, or which bookings a stylist has. Returns appointments across all the user's salons, or just one, with id, client, salon and stylist 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds genuine value beyond that by disclosing scope (all of the user's salons unless one is specified), ordering (latest first) and a hard ceiling (up to 100). It does not mention pagination or what happens when more than 100 matches exist, which is the main remaining behavioral 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 plus a short exclusion clause, front-loaded with "Use this when" so the trigger condition is the first thing read. Nearly every phrase earns its place; the only wasted content is the stylist-booking example, which points at a filter the tool cannot apply.
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 a full output schema, the description covers scope, ordering, cap and the return fields an agent needs to plan a follow-up call. The gap is the phantom stylist filter and the absence of any note on truncation when a date window exceeds 100 results.
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 the description mostly restates what the schema documents (date window, salon scoping, client, limit). It does introduce a mismatch: "which bookings a stylist has" implies a stylist filter, but no stylistId parameter exists in the schema, so that use case is unachievable as described.
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 appointments) and immediately bounds the scope: counts per day/period, cancellations and no-shows, a client's bookings, a stylist's bookings. It also carves out a clear non-purpose ("Not for the services inside an appointment"), which separates it from get_appointment and list_services without the agent needing to open either 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?
The opening clause enumerates concrete user questions that select this tool (how many booked, how many canceled/no-show, when a client is booked), which is strong when-to-use guidance. The exclusion sentence gives one when-not case, but it never names the sibling to use instead (get_appointment for a single booking, list_calendar_events for calendar entries), so routing against the other 20 tools is left partly to inference.
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's id to book them or to look up their appointments, payments or quotes. Returns up to 100 clients (20 by default) across all the user's salons or one, with id, name, salon and last edit time, optionally only those whose name matches. 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) | |
| search | No | Only clients whose name contains these words, in any order, ignoring case and accents | |
| 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 adds real behavioral detail beyond that: the default page size of 20, the hard cap of 100, cross-salon scope, and the exact field set returned. It stops short of describing ordering or how to page beyond the limit, which is the only remaining 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?
Three sentences, each doing distinct work: trigger, return shape, exclusion. The usage trigger is front-loaded and the negative scoping is placed last where it reads as a guardrail. No filler wording.
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 needn't explain return formatting, and it still summarizes the fields. Annotations cover safety, the schema covers all three parameters, and the description covers trigger, scope and exclusions — nothing an agent needs to call this 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 limit, search and salonId are already fully documented, including the default, maximum and the 24-hex id pattern. The description restates the same facts ('up to 100 clients (20 by default)', 'across all the user's salons or one', 'only those whose name matches') rather than adding new semantics, 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 ('list clients') plus the returned fields (id, name, salon, last edit time) and the cap of 100. It also distinguishes itself from the single-client sibling by explicitly excluding email, phone and notes, which are get_client territory.
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 concrete trigger ('when someone asks who their clients are, or needs a client's id to book them or to look up their appointments, payments or quotes') and an explicit exclusion ('Not for a client's email, phone or notes'), which routes the agent to get_client. Both when-to-use and when-not-to-use are present.
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 much of a product is left in the salon's stock or what is running low. Returns up to 100 stock items with unit, quantity, minimum and a low-stock flag. Not for retail prices.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items (default 50, maximum 100). | |
| search | No | Only items whose name contains these words. | |
| salonId | No | Id of the salon, from list_salons. Leave it out when the user has one salon. | |
| lowStockOnly | No | Only items at or below their minimum quantity. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| hasMore | Yes | |
| salonId | 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 value beyond them by disclosing the result cap (“up to 100 stock items”) and the shape of each item, plus a scope boundary against price data.
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 triggering condition, then the return shape, then the exclusion. Every sentence earns its place and nothing is repeated from the schema 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?
With an output schema present and full schema coverage, the description does not need to explain return values or parameter formats. It covers the trigger, the result cap and one boundary case; the only minor gap is the lack of explicit guidance toward the sibling tool for modifying stock.
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 four parameters (limit, search, salonId, lowStockOnly) are already documented in the schema. The description only loosely echoes two of them (“up to 100” and the low-stock flag) and adds no new filtering semantics, 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 pairs a concrete intent (“how much of a product is left in the salon's stock”) with the resource it reads, and states the returned fields (unit, quantity, minimum, low-stock flag). It is clearly a read/list tool and implicitly contrasts with the write-side sibling set_inventory_quantity, though it never names that sibling.
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?
“Use this when someone asks how much of a product is left... or what is running low” gives an explicit trigger condition, and “Not for retail prices” gives one exclusion. It stops short of naming the alternative tool to use for updating stock or for price data, so the routing guidance is helpful but not fully closed.
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, or which stylist to book a client with. Returns up to 100 hairdresser ids and 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 | Ids and display names of organization members with the hairdresser role; roles are organization-wide, not per salon. The ids are the ones the salon's public booking page already shows. 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 declare this is a safe, idempotent, closed read. Beyond that, the description discloses the 100-result cap and the field scope of the payload (ids and display names only, no contacts or schedules), which are real behavioral limits an agent should know before relying on the output.
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 and then the return shape and exclusion. Minor redundancy between 'stylists' and 'hairdressers' and between 'work at' and 'can be booked', but nothing wasteful enough to impede scanning.
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 an output schema, rich annotations, and a single 100%-documented parameter, the description fills the remaining gaps: who the tool is for, what it returns, and what it does not cover. Only the absence of an explicit pointer to the availability sibling keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single salonId parameter is already fully documented in the schema, including format and origin. The description adds only mild extra framing ('from the organization that owns the salon'), which clarifies scoping but does not add syntax or validation meaning 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 ('Returns up to 100 hairdresser ids and display names') and pins the scope to the organization owning the salon. It is clearly distinguishable from schedule-oriented siblings like get_salon_availability because it explicitly says 'no contact details or schedules'.
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 trigger phrasing ('when someone asks which stylists or hairdressers work at their salon or can be booked') and an explicit exclusion ('Not for stylists' days off'). It stops short of naming the alternative tool for availability, so the agent must infer the routing rather than being told directly.
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 asks to move an appointment to another day or time. Returns the moved appointment; its client, stylist, services and length stay the same and the client's reminders move with it. Not for cancelling an appointment.
| Name | Required | Description | Default |
|---|---|---|---|
| startTime | Yes | New start as an ISO 8601 time with the salon's UTC offset, such as 2026-11-20T15:30:00+01:00. | |
| appointmentId | Yes | Id of the appointment, from list_appointments. | |
| durationMinutes | No | New length in minutes. Leave it out to keep the current length. | |
| expectedLastEditTime | Yes | The lastEditTime from get_appointment or list_appointments. An appointment changed since then is refused. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| appointment | Yes | |
| previousStartTime | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the description adds value by disclosing what carries over: client, stylist, services and length persist and reminders move with the appointment. That reminder migration is a real side effect not visible in any structured field. It does not, however, surface the optimistic-concurrency refusal behavior, which is the most consequential runtime trait.
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 filler, and the triggering condition is front-loaded before the behavioral detail and the exclusion. Every clause carries new 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 shape need not be spelled out, and the annotations carry the safety profile; the description correctly focuses on intent and carry-over semantics. The only meaningful gap is the conflict/staleness refusal implied by expectedLastEditTime and the mild tension with durationMinutes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains appointmentId, startTime, durationMinutes and expectedLastEditTime thoroughly, and the baseline of 3 applies. The description adds nothing parameter-specific, and "its ... length stay[s] the same" sits slightly at odds with the optional durationMinutes field that can change the length, leaving an agent to reconcile the two.
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?
"Move an appointment to another day or time" gives a specific verb and resource, and the closing clause separates it from the cancel path. An agent can tell this apart from cancel_appointment (and from book_appointment, a new booking rather than a move) 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?
"Use this when someone asks to move an appointment" states the triggering intent explicitly, and "Not for cancelling an appointment" gives an explicit exclusion that routes the agent to the sibling tool. Both the when and the when-not are present in a single sentence pair.
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 to correct or update how much of a stock item the salon has. Returns the item with its previous and new quantity; the number given replaces the stored one. Not for adding a new stock item.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | Yes | The quantity now in stock, in the item unit. It replaces the stored quantity; work out the total first when the user gives a change. | |
| inventoryItemId | Yes | Id of the stock item, from list_inventory_items. | |
| expectedLastEditTime | Yes | The lastEditTime from list_inventory_items. An item changed since then is refused. |
| Name | Required | Description |
|---|---|---|
| item | Yes | |
| status | Yes | |
| previousQuantity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so overwrite and repeatability are structurally declared. The description reinforces this by stating the supplied number replaces the stored value and that previous and new quantities come back, but adds nothing about the optimistic-concurrency refusal path, which is the most consequential behavior 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 tight sentences with the usage trigger front-loaded and the negative scoping last. Every clause carries information, though the return-value clause is partly redundant given an output schema exists.
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 the description need not explain return values, and the concurrency guard and ID format are fully specified in the schema. What is missing is only the operational framing: that the item must first be read to obtain expectedLastEditTime and that a stale value yields a refusal.
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 every parameter's meaning, range, pattern and the lastEditTime conflict rule are already documented. The description restates the replace-vs-increment semantics already present in the quantity parameter's description, adding no new syntax or format detail; 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 ('correct or update how much of a stock item the salon has') and makes the set-not-increment semantics explicit ('the number given replaces the stored one'). It also rules out the adjacent operation ('Not for adding a new stock item'), so an agent can separate it from inventory creation 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 a clear triggering condition ('when someone asks to correct or update how much of a stock item the salon has') plus one exclusion. It does not state the prerequisite read (getting inventoryItemId and lastEditTime from list_inventory_items) or what to do when the update is refused, which the schema covers but the description does not.
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.
Use this when someone asks to change a client's name, phone, email or language. Returns the client's id, name, salon and which fields changed; contact details are never returned. Not for adding a new client.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New full name. | |
| No | New email address. | ||
| phone | No | New mobile number, with the country code when known. | |
| clientId | Yes | Id of the client, from list_clients. | |
| language | No | New language for their messages, as a code such as en or it. | |
| expectedLastEditTime | Yes | The lastEditTime from get_client or list_clients. A client changed since then is refused. |
| Name | Required | Description |
|---|---|---|
| client | Yes | |
| status | Yes | |
| changedFields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses the return payload (id, name, salon, changed fields) and a privacy rule that contact details are never returned. The main remaining gap is that it never states that omitted fields are left unchanged, which matters for a tool flagged destructive.
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 trigger condition, followed by outcome and exclusion. Every clause carries information; there is 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 six-parameter destructive update with an output schema, the description covers the trigger, the exclusion, the concurrency caveat indirectly, and the return shape. It falls short only on partial-update semantics and permission requirements, which an agent might still need to call it safely.
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 six parameters including clientId and expectedLastEditTime are already documented in the schema, and the description's field list merely mirrors those properties. It adds no syntax, format, or constraint detail beyond what structured fields provide, 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 names a specific verb and resource ('change a client's name, phone, email or language') and enumerates the mutable fields, so the agent knows exactly what the tool does. It also explicitly differentiates from the sibling create_client with 'Not for adding a new 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?
It gives an explicit trigger ('Use this when someone asks to change...') and an explicit exclusion ('Not for adding a new client'), which routes the agent to create_client for new records. No inference is required to pick between the two.
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.
book_appointmentcancel_appointmentcreate_clientget_appointment1 field changedOutput schema / properties / appointment / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "clientId": {
- "anyOf": [
- {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "endTime": {
- "anyOf": [
- {
- "maxLength": 32,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- "salonId": {
- "anyOf": [
- {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "serviceCount": {
- "maximum": 10000,
- "minimum": 0,
- "type": "integer"
- },
- "services": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "anyOf": [
- {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "name": {
- "maxLength": 200,
- "type": "string"
- },
- "price": {
- "type": [
- "number",
- "null"
- ]
- }
- },
- "required": [
- "id",
- "name",
- "price"
- ],
- "type": "object"
- },
- "maxItems": 50,
- "type": "array"
- },
- "servicesTruncated": {
- "type": "boolean"
- },
- "startTime": {
- "anyOf": [
- {
- "maxLength": 32,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "status": {
- "anyOf": [
- {
- "enum": [
- "SCHEDULED",
- "CLIENT_ARRIVED",
- "NO_SHOW",
- "CANCELED"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "id",
- "clientId",
- "salonId",
- "startTime",
- "endTime",
- "status",
- "serviceCount",
- "servicesTruncated",
- "services"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "clientId": {
+ "anyOf": [
+ {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "endTime": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ "lastEditTime": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Version to pass as expectedLastEditTime when moving or cancelling this appointment"
+ },
+ "providerIds": {
+ "description": "Stylists booked on it, as list_providers ids",
+ "items": {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+ },
+ "salonId": {
+ "anyOf": [
+ {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "serviceCount": {
+ "maximum": 10000,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "services": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "anyOf": [
+ {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The service, as list_services and book_appointment name it"
+ },
+ "name": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "price"
+ ],
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+ },
+ "servicesTruncated": {
+ "type": "boolean"
+ },
+ "startTime": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "enum": [
+ "SCHEDULED",
+ "CLIENT_ARRIVED",
+ "NO_SHOW",
+ "CANCELED"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "clientId",
+ "salonId",
+ "providerIds",
+ "startTime",
+ "endTime",
+ "status",
+ "lastEditTime",
+ "serviceCount",
+ "servicesTruncated",
+ "services"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]list_appointments3 fields changedOutput schema / properties / appointments / items / properties / lastEditTimeAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Version to pass as expectedLastEditTime when moving or cancelling it"
+}Output schema / properties / appointments / items / properties / providerIdsAdded value: +{
+ "description": "Stylists booked on it, as list_providers ids",
+ "items": {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}Output schema / properties / appointments / items / requiredPrevious value: -[
- "id",
- "clientId",
- "salonId",
- "startTime",
- "endTime",
- "status"
-]New value: +[
+ "id",
+ "clientId",
+ "salonId",
+ "providerIds",
+ "startTime",
+ "endTime",
+ "status",
+ "lastEditTime"
+]list_clients1 field changedInput schema / properties / searchAdded value: +{
+ "description": "Only clients whose name contains these words, in any order, ignoring case and accents",
+ "maxLength": 100,
+ "minLength": 1,
+ "type": "string"
+}list_inventory_itemslist_providers3 fields changedOutput schema / properties / providers / descriptionPrevious 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."New value: +"Ids and display names of organization members with the hairdresser role; roles are organization-wide, not per salon. The ids are the ones the salon's public booking page already shows. Contact details, avatar URLs, role records, schedules and organization data are excluded."Output schema / properties / providers / items / properties / idAdded value: +{
+ "anyOf": [
+ {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The id book_appointment takes in providerIds"
+}Output schema / properties / providers / items / requiredPrevious value: -[
- "displayName"
-]New value: +[
+ "id",
+ "displayName"
+]reschedule_appointmentset_inventory_quantityupdate_clientopen_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_overviewAppointments, clients, sales and reviews for salons and spas.
Salon and clinic appointments: check availability, hold slots, take deposits, move and cancel.
Salon, spa and clinic management: bookings, clients, staff, sales reports, inventory and marketing.
Bookings, clients, reviews and reports for beauty businesses.
Add one secure layer between your agents and this server.