Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

fresha_search_venues

Search Fresha salons, barbers and wellness venues by text, location, price, gender, award or treatment, then filter and page results with cursor-based navigation.

Instructions

Search Fresha venues by text, place, price, gender, award and treatment. Returns one page of Fresha's (fresha.com) salon, barber and wellness venue search: each venue's id, slug, name, canonical page, address, business type, rating and rating count, rating badge, cover image and distance, plus the gateway's own match count and a forward cursor. Pass a latitude/longitude pair to search a place (with neither, the gateway falls back to its own default centre and the response reports the centre it used). query, min_price, service_gender (EVERYONE, MALE, FEMALE), awards (BEST_IN_CLASS, HIGHLY_RECOMMENDED), sort (DISTANCE, RATING, RECOMMENDED) and the three treatment ids from fresha-taxonomy (category:, tag:, treatment:/) each change the result set. first is 1 to 200 and larger values are rejected because the gateway rejects them too. Paging is cursor-based: pass next_cursor back as after while has_next_page is true, and note that a malformed cursor silently restarts the list at page one. count 0 with no error is an honest empty result for a valid filter. Search results carry no price: a venue's own service menu, read through fresha-venue, is the only place this API publishes one.

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": "fresha_search_venues"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Result ordering
`after`	No	Forward cursor from next_cursor; omit for the first page
`first`	No	Venues per page, default 20, maximum 200
`query`	No	Free-text query matched by Fresha's venue search
`awards`	No	Fresha award filter
`latitude`	No	Latitude of the search centre; supply with longitude
`longitude`	No	Longitude of the search centre; supply with latitude
`min_price`	No	Minimum service price in the market's own currency
`service_gender`	No	Venue gender focus
`treatment_tag_id`	No	Taxonomy tag id from fresha-taxonomy, e.g. tag:haircut
`treatment_type_id`	No	Taxonomy treatment id from fresha-taxonomy, e.g. treatment:nails/wedding-nails
`treatment_category_id`	No	Taxonomy category id from fresha-taxonomy, e.g. category:nails

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A4.6/5.0

Behavior5/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 well: it discloses cursor-based paging, that a malformed cursor silently restarts at page one, that first is capped at 200 and larger values are rejected, that a default centre is used when no coordinates are given and reported back, and that count 0 with no error is a genuine empty result.

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?

Front-loads purpose and the return shape, then moves to filters, paging, edge cases and the price caveat — a sensible ordering with little redundancy. It is one dense block rather than broken into scannable segments, and a few clauses (e.g. restating that the gateway rejects oversized first) 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 12-parameter search tool with no output schema and no annotations, the description covers what is needed: result fields, pagination contract, filter semantics, failure modes and where prices actually live. An agent could call this correctly without opening any other reference.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description still adds meaning by spelling out the enum values inline, the taxonomy id formats (category:/tag:/treatment:), the 1-200 bound on first, and the fact that each filter changes the result set. It does not clarify the currency or units of min_price or how the sort enum interacts with distance-only results, so it is not fully additive.

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?

Opens with a specific verb and resource ('Search Fresha venues') and immediately enumerates the filter axes (text, place, price, gender, award, treatment). It then describes exactly what one page of results contains (id, slug, name, canonical page, address, business type, rating, cover image, distance, match count, cursor), which lets an agent distinguish it from a plain venue-detail tool.

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

Usage Guidelines4/5

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

Gives clear operational context: pass latitude/longitude to search a place, use the three treatment ids from fresha-taxonomy, and read prices via fresha-venue instead. It does not explicitly exclude or compare against a sibling such as a landing/lookup venue tool, so routing between Fresha search variants is left partly implicit.

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

Deploy Server