Skip to main content
Glama

fresha_landing_venues

Read-only

List the venues Fresha publishes on one of its own pre-rendered landing pages and return each venue's name, canonical page URL, published business types, postal address with coordinates, average rating with its rating count, coarse price band and image. Read a plain city page with city alone, a business-type page by adding business_type, or a treatment-type page by adding treatment_type; the two facets are mutually exclusive. city is the page's own value with its country prefix, such as us-new-york, and a combination Fresha does not publish is a not-found. There is no pagination: the page pre-renders a fixed list (about 30 venues for a city, 130 for a facet page), so count is that page's length and never a total. Use fresha_search_venues when you need to walk a market rather than read one page, and fresha_venue for the service menu behind any venue listed here.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "city": "<city>"
    },
    "name": "fresha_landing_venues"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityYesRequired city landing value with its country prefix, e.g. us-new-york, as Fresha's own city landing pages are addressed. A bare city name does not resolve upstream and is rejected here.
business_typeNoOptional business-type slug, e.g. hair-salons. Mutually exclusive with treatment_type; with neither, the plain city landing page is read.
treatment_typeNoOptional treatment-type slug, e.g. hair-colouring. Mutually exclusive with business_type.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the supplied readOnlyHint/openWorldHint annotations, it discloses that there is no pagination, that the page pre-renders a fixed list (~30 venues for a city, ~130 for a facet page), that count is that page's length and never a total, and that an unpublished combination returns not-found. These are exactly the behavioral traits an agent could otherwise misjudge, especially the count-is-not-a-total caveat.

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?

It is front-loaded with the purpose and output contents, then moves to invocation modes, then to the pagination caveat, then to sibling routing — a sensible order with no filler. It is dense and information-rich, but a couple of the sentences pack multiple claims (format, example, and error behavior together), slightly reducing scannability.

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 3-parameter read-only tool with an output schema, everything an agent needs to call it correctly is present: required input format, mutual exclusivity, error semantics, list size, and where to go for alternatives. Return value structure need not be explained since an output schema exists, and the description still summarizes it usefully.

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 100%, so the baseline is 3, and the description earns a bump by specifying that city is the page's own value with its country prefix, giving the us-new-york example, and restating the business_type/treatment_type exclusivity and the not-found consequence. The only minor gap is that it does not give format hints for the two facet slugs beyond the schema examples.

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 description opens with a specific verb and resource ("List the venues Fresha publishes on one of its own pre-rendered landing pages") and then enumerates exactly what each result contains: name, canonical URL, business types, postal address with coordinates, rating plus count, price band, image. It also distinguishes the three page modes it can read, so an agent can tell it apart from the search and venue siblings.

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 gives explicit routing rules: read the plain city page with city alone, add business_type for a business-type page, add treatment_type for a treatment-type page, and states those facets are mutually exclusive. It also names the alternatives and the condition that selects them — fresha_search_venues for walking a market, fresha_venue for the service menu behind a listed venue.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.