Find US nail salons and book confirmed appointments: menus, prices, hours, live open times.
Scored across 4 tools
Each tool targets a distinct action and resource: searching salons (find_salons), retrieving one salon's details (get_salon), checking open times (check_availability), and booking (book_appointment). find_salons vs get_salon could superficially overlap but the descriptions make the search-vs-detail boundary clear. No two tools can be confused for the same operation.
All four tools follow a strict verb_noun snake_case pattern (book_appointment, check_availability, find_salons, get_salon). The verbs are distinct and predictable, and the noun always names the domain entity. No mixing of conventions.
Four tools is on the lean side but each earns its place in the search → inspect → check → book flow. It is well-scoped for a narrow booking domain, though a slightly larger set might feel more robust.
The online booking lifecycle is fully covered: find salons, get details/menu, check availability, and book, with find_salons even handling paging and non-bookable salons. The only gaps (viewing or cancelling an existing booking) are explicitly called out as phone-only, so agents have no dead ends within the online scope.
Books an appointment. Real and immediate: the salon holds the time and the customer gets a confirmation text. It can't be cancelled or changed online, only by calling the salon. Repeating the same call returns the same booking, never a second one.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The salon's slug. | |
| start_at | Yes | ISO start time of an open slot for this salon and service. | |
| agent_name | No | Name of the AI assistant making the booking, e.g. "Claude". The salon sees "Booked by <agent_name>". | |
| service_id | Yes | The service's id on the salon's menu. | |
| customer_name | Yes | The customer's name, as the salon should greet them. | |
| customer_phone | Yes | The customer's mobile number; the confirmation text goes here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=true and openWorldHint=true; the description reinforces these with concrete semantics ('repeating the same call returns the same booking, never a second one' and 'can't be cancelled or changed online'). It adds the real-world side effects (salon holds the time, customer receives a confirmation text) that the annotations cannot express, though it says nothing about permissions, failure modes, or rate limits.
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?
Four short sentences, front-loaded with the core action and then the consequences; each sentence carries weight. The opening 'Books an appointment' largely restates the title, which is the only wasted line.
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 no-output-schema, six-parameter mutation tool, the description covers the side effects (confirmation text, held slot) and idempotent behavior an agent needs to act safely. It does not say what the response contains (e.g. a booking identifier), which leaves a minor gap, but nothing critical 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 all six parameters are already documented in the schema, and the description adds no parameter-level meaning (it never explains slug, service_id, start_at format, or the agent_name visibility). Baseline 3 is appropriate when the schema does the work.
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 ('Books an appointment') and adds the essential nature of the operation: real, immediate, holds the slot, sends a confirmation text. It never names the sibling tools (check_availability, find_salons) or explicitly says the slot must be verified first, so it is clear but not fully differentiated.
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?
Usage context is implied rather than stated: the caller learns the booking is irreversible online and can only be undone by phone, which nudges toward caution, and start_at being 'an open slot' implies availability must be checked first, but no alternative tool is named and no explicit 'call check_availability before this' instruction appears.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open start times for one service with any technician, each as an ISO start_at and a local label. Searches from now when no date is given; up to 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD in the salon's local time. | |
| days | No | How many days from date. Default 1. | |
| slug | Yes | The salon's slug. | |
| service_id | Yes | The service's id on the salon's menu. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that: the default search start (now) and the 7-day cap on the window, which constrain how results are produced.
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 no filler; the what-it-returns clause is front-loaded before the default-window behavior. Every clause carries information the agent can act on.
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 no output schema, the description correctly specifies the return shape (ISO start_at plus local label), and it covers the default date behavior and window limit. It omits ordering/pagination details and doesn't state what an empty result means, but nothing blocking correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the schema caps days at 7 and defaults date handling. The description adds meaning the schema does not: availability is 'with any technician' (no technician filter needed/possible) and an absent date defaults to searching from now.
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 (open start times for one service) and even describes the return shape (ISO start_at plus local label). It implicitly contrasts with book_appointment by being the read-only lookup, but it never names a sibling, so it falls short of a 5.
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 useful default context ('searches from now when no date is given; up to 7 days'), which tells the agent how to call it without a date. However, there is no explicit when-to-use/when-not guidance or pointer to book_appointment for the follow-up write, leaving the workflow relationship to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nail salons on Lacquer in a US city + state or ZIP code, optionally narrowed by salon name. Up to 20 per call; "total" says how many match, and "offset" pages through the rest. Salons that take online bookings ("books_online": true) come first; a salon with books_online false has no open times online and is listed with its phone number. Within that, Lacquer partner salons ("partner": true) come first; the rest rotate daily, and the order says nothing about quality.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit ZIP code. Used instead of city/state when given. | |
| city | No | City, e.g. "Santa Monica". Used together with state. | |
| name | No | Part of the salon's name. | |
| limit | No | ||
| state | No | US state, "CA" or "California". | |
| offset | No | Number of results to skip; a result's next_offset gives the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description goes well beyond them: pagination model (20 per call, total, offset), a three-level result ordering rule (books_online, then partner, then daily rotation), and an explicit disclaimer that ordering says nothing about quality. That ordering disclosure is the kind of thing an agent cannot infer and would otherwise misread as relevance ranking.
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-loads what the tool returns and the filter inputs, then packs the non-obvious ranking behavior into two compact sentences. No filler or restated tool name; every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully explains the return shape (total, offset paging, phone fallback for non-bookable salons) and the ordering. It stops short of covering edge cases such as what happens if zip and city/state are both supplied, or the default page size when limit is omitted.
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 83%, so the schema already documents zip, city, name, state and offset semantics. The description mostly restates those constraints ('Up to 20 per call', 'offset pages through the rest') without adding format details, defaults, or precedence rules beyond the schema's own 'zip is used instead of city/state' note.
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 (find nail salons on Lacquer) with the exact scoping inputs (US city + state or ZIP) and an optional name filter. The listing nature ('Up to 20 per call', 'total' says how many match) makes it clearly a search/list tool rather than a single-record lookup like get_salon.
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?
Usage is implied rather than stated: the description explains that salons with books_online=true are bookable and others are listed with only a phone number, which hints at when this tool's results are actionable, but it never says when to reach for this versus get_salon or check_availability, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A salon's address, phone, weekly hours and full service menu (service_id, price, duration).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The salon's slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful payload context by enumerating the returned fields, including the nested menu shape (service_id, price, duration), which no output schema provides. It omits error behavior for an unknown slug, keeping it short of a 5.
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?
A single sentence fragment that front-loads the resource and packs the full return payload into a parenthetical. Zero filler and nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup whose annotations cover safety, the description supplies the missing return-value information that would otherwise come from an output schema. Only the failure mode for an invalid slug is 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 coverage is 100% with a single slug parameter whose schema already describes it as 'The salon's slug.' The description adds no syntax, format, or lookup semantics (exact match vs fuzzy) beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (a salon) and enumerates exactly what it returns — address, phone, weekly hours, and the full service menu with service_id, price, and duration. It is clear and specific, though it lacks an explicit verb and never contrasts itself with the sibling find_salons, leaving the lookup-vs-search distinction to inference from the name.
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?
There is no when-to-use guidance, no statement that this requires a known slug, and no mention of alternatives such as find_salons for discovery. An agent must infer from the name alone that this is the detail lookup to use after obtaining a slug.
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_appointment4 fields changedInput schema / properties / agent_name / descriptionPrevious value: -"Your own product name, e.g. \"Claude\" or \"ChatGPT\". The salon sees \"Booked by <agent_name>\"."New value: +"Name of the AI assistant making the booking, e.g. \"Claude\". The salon sees \"Booked by <agent_name>\"."Input schema / properties / service_id / descriptionAdded value: +"The service's id on the salon's menu."Input schema / properties / slug / descriptionAdded value: +"The salon's slug."Input schema / properties / start_at / descriptionPrevious value: -"An ISO start_at exactly as returned by check_availability."New value: +"ISO start time of an open slot for this salon and service."check_availability2 fields changedInput schema / properties / service_id / descriptionPrevious value: -"From get_salon."New value: +"The service's id on the salon's menu."Input schema / properties / slug / descriptionAdded value: +"The salon's slug."find_salons2 fields changedInput schema / properties / city / descriptionPrevious value: -"City, e.g. \"Santa Monica\". Pair with state."New value: +"City, e.g. \"Santa Monica\". Used together with state."Input schema / properties / offset / descriptionPrevious value: -"Skip this many results; use next_offset from the previous call."New value: +"Number of results to skip; a result's next_offset gives the next page."get_salon1 field changedInput schema / properties / slug / descriptionPrevious value: -"Salon slug from find_salons."New value: +"The salon's slug."find_salons1 field changedInput schema / properties / offsetAdded value: +{
+ "description": "Skip this many results; use next_offset from the previous call.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}book_appointmentcheck_availabilityfind_salonsget_salonFind nail studios near you, see services, prices and free times, and prepare a booking to confirm.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Search and book appointments at local businesses. Barbershops, salons, spas, and more.
Find participating local service providers and book live appointment times.
Add one secure layer between your agents and this server.