Find salons, barbershops, spas and med spas on Belcome, see services, prices and open times.
Scored across 11 tools
Most tools target clearly distinct resources: find_business (search), get_business (hours/contact), list_services, list_team, list_addons, list_gallery, list_offers, list_reviews, find_slots. The only real friction is among the three 'info' getters — get_about, get_booking_policy and get_business all answer questions about one business, and 'studio policies (late arrival, parking)' in get_about sits close to 'cancellation window / no-show fees' in get_booking_policy, which could cause misselection for a policy question.
Every name follows a strict verb_noun snake_case pattern drawn from a small verb set (find_, get_, list_) with the noun identifying the resource. The verbs are used semantically consistently: find_ for search/availability, get_ for single-object detail, list_ for collections.
Eleven tools is well within the sweet spot and each maps to a distinct facet of a salon booking page (search, location info, services, team, addons, gallery, offers, reviews, policies, about, slots). No tool looks redundant or like filler.
For a read-only discovery surface that deliberately hands off booking via booking_url and purchasing via shop_url, coverage is strong: search → location → services/team/addons → availability → reviews/policies. Gaps are minor but real — there is no way to check a specific professional's availability without first picking a service, no multi-location/chain lookup, and no tool to refine slots by date-range filters beyond the fixed 14 days.
Find salons, barbershops, spas and studios that take online bookings on Belcome, by name, service or city. Returns up to 10 businesses with their locations and booking page.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | City, state or ZIP code to narrow the search, e.g. "Orlando" or "02601". | |
| query | Yes | Business name, service or kind of place, e.g. "balayage", "barber", "Cape Cod Nails". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a concrete behavioral detail beyond that: results are capped at 10 businesses and include locations and a booking page, which tells the agent what to expect in the response and that result sets are bounded.
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 filler, front-loaded with the resource and scope before the return behavior. Every clause 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?
For a simple two-parameter read tool with no output schema, the description covers the return shape (up to 10 businesses with locations and booking page), which is the main gap the missing output schema would otherwise create. Minor omissions (empty-result behavior, whether the cap is paginable) keep it short of perfect.
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 with examples in the schema. The description's "by name, service or city" loosely maps to query and near but adds no syntax, format, or matching-behavior detail beyond the schema — the baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Find) and resource (salons, barbershops, spas, studios taking online bookings on Belcome), so the function is unmistakable. It does not explicitly contrast itself with the siblings find_slots or list_services, but the resource boundary is clear enough that an agent can distinguish them.
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?
"by name, service or city" implies the supported lookup modes and therefore how to use it, but there is no explicit when-to-use framing, no when-not, and no pointer to find_slots for availability or list_services for service catalogs. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find open times for one service at a business, up to 14 days. Each time comes with a booking_url that opens the business's booking page with the service, professional and time already chosen; give that link to the person to confirm with their name and phone.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | First day, YYYY-MM-DD in the location's timezone. Defaults to today. | |
| through | No | Last day, YYYY-MM-DD, at most 13 days after from. Defaults to a week. | |
| business | Yes | The business id returned by find_business. | |
| staff_id | No | Only this professional. Leave out for anyone available. | |
| service_id | Yes | Service id from list_services. | |
| location_id | No | Location id. Defaults to the first location. | |
| start_time_from | No | Optional earliest start time, inclusive, HH:MM (24-hour) in the location timezone on every searched day. For afternoon use 12:00. | |
| start_time_before | No | Optional latest start time, exclusive, HH:MM (24-hour) in the location timezone on every searched day. Must be later than start_time_from if both are given. Filters appointment starts, not end times. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds real behavioral value by disclosing the 14-day search ceiling and, critically, that each result carries a pre-filled booking_url — output semantics that matter because there is no output schema. It does not say what an empty result looks like or whether availability is live.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with what the tool returns and scoped by the day limit. Nothing redundant; 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 8 fully documented parameters, read-only annotations, and no output schema, the remaining burden is describing return values and next steps — which the booking_url sentence does precisely. Nothing needed to invoke or use the result 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%, with each of the 8 parameters documented including timezone and HH:MM conventions, so the baseline applies. The description only restates the one-service scope and the date window, adding little 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 ('Find open times for one service at a business') plus a hard scope limit ('up to 14 days'). That is clearly distinct from every sibling, which are all catalog/metadata listings (list_services, find_business, get_booking_policy).
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?
Explains the downstream workflow explicitly: hand the returned booking_url to the person so they confirm with name and phone. It does not name alternatives or state when NOT to call it (e.g. use list_services first to get service_id), leaving that to the schema's parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the business says about itself on its booking page: tagline, "about us" story, studio policies (late arrival, parking, what to bring) and extra text blocks. Use it for "what is this place like?" or "what should I know before I go?".
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, non-destructive, closed-world behavior, so the bar is lower. The description carries the remaining burden by disclosing what content comes back (tagline, story, policies, free-text blocks), which is the key behavioral fact for a content-read tool. It doesn't say what happens when the business hasn't filled these in, leaving empty-result behavior unstated.
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 with zero waste: the first front-loads what is returned, the second frames the caller intents that select this tool. No repetition of the name beyond what's needed for scoping.
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 must and does describe the returned content well enough to call confidently. The only gap is edge-case behavior (missing about text, multiple locations) which the schema partially covers via the location_id default.
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%: both `business` and `location_id` are documented in-schema, including the default-to-first-location behavior. The description adds no parameter guidance of its own, 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?
Names the specific resource (the business's self-description on its booking page) and enumerates what it contains: tagline, about-us story, studio policies, extra text blocks. That content list distinguishes it from siblings like get_business (structured facts) and get_booking_policy (scheduling rules). It never names an alternative sibling explicitly, so it stops 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 concrete trigger intents ("what is this place like?", "what should I know before I go?") that map cleanly to a caller's question, which is more actionable than most usage guidance. It does not state when to prefer get_business or get_booking_policy instead, so boundary cases with siblings are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancellation window, whether the business approves bookings, how far ahead one can book, deposit or prepayment and late-cancel or no-show fees. Use it for "can I cancel?", "do I pay a deposit?" before handing over booking_url.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
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 a useful workflow constraint (call before exposing booking_url) but says nothing about data freshness, per-location variation, or return shape.
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: a dense field enumeration followed by concrete usage intents. No filler, and the returned-attribute list is front-loaded, though the opening noun phrase is slightly list-like rather than leading with a verb.
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 carries the burden of describing return content, and it does so by enumerating the policy dimensions. Combined with a fully documented two-parameter schema and read-only annotations, an agent has enough to call it correctly; only the response structure remains unspecified.
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 both 'business' and 'location_id' fully documented including their source tool and default behavior. The description adds no parameter guidance beyond the schema, 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 enumerates the exact policy attributes returned: cancellation window, approval requirement, booking horizon, deposit/prepayment, and late-cancel/no-show fees. That makes the resource content unmistakable and separates it from siblings like find_slots or list_services, though no explicit verb ('returns') is used.
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 concrete caller intents ('can I cancel?', 'do I pay a deposit?') and a sequencing rule: check this before handing over booking_url. No explicit when-not or named alternative is offered, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opening hours, phone, address, map point, languages, rating, links and frequently asked questions of one business location. Use it for "is it open on Sunday?" or "what is the phone number?" before or after find_slots.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
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 that results cover exactly one location and that location defaults, but says nothing about error behavior when a business id is unknown or about response size/pagination. Adequate, not rich.
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 returned data then the usage trigger. Every clause carries information; nothing is padding.
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 enumerates what the response contains, and both parameters are covered by the schema. The only gap is failure behavior for bad ids, which is minor for a simple read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented in-schema, including that business comes from find_business. The description only restates the single-location scope, adding nothing about id format or what happens with an invalid location_id. 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?
Names the exact resource and enumerates the fields returned (hours, phone, address, map point, languages, rating, links, FAQ) for a single business location, which separates it clearly from the list_* siblings. There is no explicit verb, but the noun phrase is specific enough that an agent knows precisely what it gets back.
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 use-case questions ("is it open on Sunday?", "what is the phone number?") and positions the call before or after find_slots. It does not state when NOT to use it or when list_services/list_team would be better, 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.
Add-ons a business offers online at one location (a treatment extra, a longer session): name, duration, price and the services each one can be added to. They are picked on the booking page together with the main service, never booked alone.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only and non-destructive, which covers the primary behavioral safety traits. The description doesn't add much new behavioral detail (e.g., rate limits, specific API quirks), but it provides strong contextual framing for the data type itself. Given the hints, a 3 is appropriate as the description adds contextual value without unnecessary repetition of security/mutability traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is focused and efficient, dedicating the text entirely to defining the resource type and its business logic constraints. It avoids redundant phrasing and is structured logically.
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?
While the tool is complete for its specific purpose, it lacks guidance on the expected format of the returned add-on data (e.g., whether it's a flat list or nested objects containing the price, duration, etc.). Adding a note on the response structure would enhance completeness, but it is strong for a listing tool.
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%, meaning the schema already details both `business` and `location_id`. The description offers no additional meaning or semantic constraints beyond what the schema provides, resulting in the baseline score of 3.
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 clearly defines what 'add-ons' are within the business context (a treatment extra, a longer session) and what the tool fetches. It successfully distinguishes this concept from general services or offerings.
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 description provides a specific use case constraint: 'never booked alone,' implying they are always paired with a main service. It also dictates their location ('on the booking page'), which guides the agent on *when* to use them versus other list/booking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The photos the business shows on its booking page (its work: cuts, colour, nails, tattoos...), each with the service it is tagged to and a booking link for that service. Use it for "can I see their work?" or "do they do this style?".
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, non-destructive, closed-world safety profile, so the bar is lower. The description adds real value by describing the shape of what comes back (photo plus tagged service plus booking link), which matters since there is no output schema. It doesn't mention pagination, empty galleries, or ordered results.
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 what the tool returns, followed by the use case. The parenthetical examples of work types are illustrative rather than filler, and nothing is 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 two-parameter read tool with full schema coverage and no output schema, the description covers both the return content and the selection intent. Only minor operational details (paging, empty results) are missing, which is acceptable 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 description coverage is 100%, so both business and location_id are already documented, including the default-first-location behavior. The description adds only implicit meaning (the gallery belongs to that business/location) and no format or edge-case detail, 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 clearly identifies the resource (photos the business displays on its booking page) and enriches it with what each entry carries: a tagged service and a booking link. It doesn't explicitly distinguish itself from siblings like get_about or list_services, but the resource is specific enough that an agent can tell it apart.
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 two concrete user intents ("can I see their work?" and "do they do this style?") that map cleanly to when this tool is the right pick. It stops short of naming alternatives or exclusions, so it lands at clear context without full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Session packages and memberships a business sells online, and whether it sells gift cards, with prices. Give the person shop_url to buy: payment happens there, never in the chat.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
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 context beyond them: results include prices, a shop_url is provided, and purchasing must happen on that page, not in chat — an important constraint on downstream behavior. It doesn't cover empty results or pagination, keeping it from 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?
Two tight sentences with zero filler; the resource scope comes first and the purchase-routing constraint second, which is the right order for an agent reading top-down.
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 does the necessary work of naming what comes back — packages, memberships, gift-card availability, prices — and how to act on shop_url. It falls slightly short on edge cases (no offers, multiple locations) but is otherwise sufficient for a simple read.
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 both business and location_id fully documented in the schema, so the baseline 3 applies. The description says nothing about location scoping or the default-to-first-location behavior that the schema documents.
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?
It states the resource precisely: session packages, memberships and gift-card availability, plus prices. It's clear and specific, but there's no sibling differentiation — an agent can't tell from the description alone how this differs from list_services (services vs. packages), which is the closest neighbor.
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 by the resource name; the description does not say when to call this versus list_services or get_business. The one explicit instruction — "give the person shop_url to buy" — is post-retrieval routing guidance rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The average rating and the latest client reviews of a business location, as shown on its booking page. Empty when the business does not collect reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses the empty-result condition when the business does not collect reviews, which matters for interpreting output. It stops short of saying how many reviews 'latest' returns or whether the set is paginated.
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 short sentences with no filler; the core content is front-loaded and the edge case is a single tight clause. 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?
For a simple two-parameter read tool with no output schema, the description covers what is returned (average rating, latest reviews) and the empty case, which is what an agent needs to interpret results. It could be more complete by clarifying the volume or ordering of 'latest' reviews.
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 business and location_id are already fully documented with cross-references to find_business. The description adds nothing about parameter behavior (such as how location_id defaulting affects which reviews are returned), 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 resource (average rating plus latest client reviews of a business location) and the context it mirrors (the booking page). It is distinguishable from the sibling list_* tools by domain, though it never names a sibling to contrast with.
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 only implied: an agent can infer it should call this when review content is needed for a business/location, but there is no explicit when-to-use, prerequisite, or alternative (e.g., versus get_business, which might also surface rating data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the services a business offers online at one location: name, duration, price and the professionals who do each one. Use the ids with find_slots.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
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 only scoping context ('online at one location', default to first location) and does not describe pagination, result caps, or auth requirements, so it merits the baseline rather than more.
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, no filler: the first defines output and scope, the second gives the downstream usage. The key information is front-loaded and nothing is 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?
With annotations covering safety, full schema coverage, and no output schema, the description correctly compensates by enumerating the returned fields (name, duration, price, professionals). An agent has everything needed to call it and chain it into find_slots.
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 (business, location_id) are already documented, including the default-to-first-location behavior. The description's 'at one location' phrase reinforces location_id semantics but adds no format or syntax detail beyond the schema, making the baseline 3 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?
States a specific verb (List) and resource (services a business offers) and enumerates the returned fields: name, duration, price, professionals. It also distinguishes the tool from the sibling find_slots by positioning itself as the id source for that call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing guidance ('Use the ids with find_slots') and the schema ties 'business' to find_business output, so an agent knows where this fits in the flow. It stops short of stating when NOT to use it (e.g. when services are already cached or when searching across locations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The professionals who take online bookings at a business location: name, role, short bio, the services each one does and their rating. Use the staff_id with find_slots to book with a specific person.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | The business id ("business" field) returned by find_business. | |
| location_id | No | Location id from find_business. Defaults to the first location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and destructiveHint=false already covering the safety profile, the description adds useful substance by specifying what is returned (name, role, short bio, per-person services and rating) in the absence of an output schema. It doesn't mention pagination, empty results, or what happens if the location has no staff.
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 first describes the payload, the second routes the agent to the booking flow. No filler, and the most decision-relevant information (what you get) comes first.
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 read-only list tool with no output schema, describing the returned fields plus the staff_id-to-find_slots handoff covers what an agent needs to use it correctly. Only edge cases (no staff at a location, multiple locations) are 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 the business and location_id parameters are already documented in the schema, including the default-location behavior. The description adds no further parameter semantics beyond noting that staff_id (an output field) is the input to find_slots, 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 identifies the resource precisely (the bookable professionals at a business location) and enumerates the fields returned (name, role, bio, services, rating), which is more informative than the tool name alone. It doesn't use an explicit verb like 'list', but the intent is unmistakable and it is clearly distinct from siblings such as find_business or list_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete downstream guidance: 'Use the staff_id with find_slots to book with a specific person', which tells the agent exactly which sibling this output feeds. It stops short of explicit exclusions or saying when a different sibling (e.g., find_business) is the better first step.
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.
find_slots2 fields changedInput schema / properties / start_time_beforeAdded value: +{
+ "description": "Optional latest start time, exclusive, HH:MM (24-hour) in the location timezone on every searched day. Must be later than start_time_from if both are given. Filters appointment starts, not end times.",
+ "type": "string"
+}Input schema / properties / start_time_fromAdded value: +{
+ "description": "Optional earliest start time, inclusive, HH:MM (24-hour) in the location timezone on every searched day. For afternoon use 12:00.",
+ "type": "string"
+}list_addonslist_galleryget_aboutget_booking_policyget_businesslist_offerslist_reviewslist_teamfind_businessfind_slotslist_servicesSearch and book appointments at local businesses. Barbershops, salons, spas, and more.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Find US nail salons and book confirmed appointments: menus, prices, hours, live open times.
Real-time booking for Korean beauty & wellness shops — search availability, get a booking link.
Add one secure layer between your agents and this server.
