Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

booksy_businesses

List and filter Booksy salon and barber businesses in a chosen country by category, treatment, free-text query, or location, with pagination, sorting, open-now, offers, and bulk ID lookup.

Instructions

List and filter Booksy businesses in one market. Returns one page of Booksy's (booksy.com) salon and barber marketplace for a country, filtered by a top-level category, a treatment id or a free-text query, and optionally scoped to a location. This reads the Android customer app's own JSON API (https://{country}.booksy.com/core/v2/customer_api/businesses/), which is offset-paginated: page_size is honoured up to 100 (larger values are silently clamped, so they are rejected here) and total is the marketplace's own match count. total saturates at 10000, and total_capped reports when the number is a ceiling rather than an exact count. category and treatment are INTEGER ids — a slug is rejected upstream — taken from booksy-categories and booksy-treatment-hints respectively; they may be combined. The listing filters the app's own client sends are supported as well: sort_order (distance, score, top_rated, by_ids — by_ids requires business_ids and returns the businesses in the order supplied; score is the default ranking and returns the same order as no sort_order), gender (M, F, R — it reorders the page for a stated client gender but does not filter it, so total is unchanged, and an unrecognised value is rejected here because Booksy silently ignores it), open_now and has_special_offers (booleans that restrict the page to businesses open now or running an offer; open_now is sent upstream as 1/0 because Booksy rejects true/false on it), and business_ids (a comma-separated bulk lookup of at most 100 ids, which also satisfies the requirement for one of category, treatment or query). location_id and location_name are alternatives, and an unknown location_name is not an error: the server silently falls back to the whole country, so read the response's location node instead of assuming the name was applied. A page past the end is an honest empty businesses array with total intact; page 0 is rejected. Records carry catalogue metadata, geo, promotion flags and aggregate review scores only — never reviews, reviewer identities, staff or availability.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "booksy_businesses"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number, default 1
queryNoFree-text search term; at least one of category, treatment or query is required
genderNoRanking personalisation for a stated client gender; reorders but does not filter
countryNoMarket host
categoryNoTop-level category id from booksy-categories (integer, not a slug)
open_nowNoOnly businesses open now
page_sizeNoRecords per page, default 20, maximum 100
treatmentNoTreatment id from booksy-treatment-hints (integer, not a slug)
sort_orderNoListing order; distance needs a location, score is the default ranking, by_ids requires business_ids
location_idNoBooksy location id, e.g. 30067 for New York City
business_idsNoComma-separated business ids for a bulk lookup, at most 100; required with sort_order=by_ids
location_nameNoLocation name for the server to resolve, e.g. New York City
has_special_offersNoOnly businesses running a special offer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full behavioral burden and does so unusually well: it discloses page_size clamping, total saturation at 10000 with total_capped, that gender reorders rather than filters, that open_now is transcoded to 1/0 upstream, that an unknown location_name silently falls back to the whole country, and that records exclude reviews, staff and availability. These are exactly the non-obvious traits an agent needs. Scored 3 rather than higher only against the strict rubric bar for descriptions that must shoulder everything alone, though on evidence this is near-exemplary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and pagination constraints are front-loaded and essentially every clause conveys non-redundant behavior. However, it is a single dense paragraph of interleaved parameter notes that would read faster as a short list, and a few clauses (page 0 rejection, open_now encoding) could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter tool with no annotations and no output schema, nothing material is missing: pagination semantics, enum interactions, id-sourcing, fallback behavior, and what records do and do not contain are all covered. An agent could invoke this correctly without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning the schema cannot: category/treatment must be integer ids and slugs are rejected upstream, score and no-sort_order yield the same order, gender reorders without changing total, and unrecognised gender values are rejected here because Booksy would silently ignore them. It also explains the location_name fallback so the agent knows to read the response's location node.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('List and filter Booksy businesses in one market') and immediately qualifies it as the salon/barber marketplace listing filtered by category, treatment or query. The singular sibling `booksy_business` is implicitly distinguished by the emphasis on paged listing and filtering, and the upstream endpoint is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the hard precondition ('at least one of category, treatment or query', restated as business_ids satisfying it), the alternatives for location (location_id vs location_name), when sort_order variants are valid ('by_ids requires business_ids', 'distance needs a location'), and the when-not cases ('page 0 is rejected', a past-the-end page returns an empty array). It also routes the agent to booksy-categories and booksy-treatment-hints for id sourcing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools