Crawlora MCP

fresha_taxonomy

Read-only

List Fresha's treatment taxonomy and return the ids that fresha_search_venues accepts as treatment_category_id, treatment_tag_id and treatment_type_id, each with its display label, kind (TreatmentCategory, TreatmentTag or TreatmentType) and an icon for categories. Ids take the forms category:, tag: and treatment:/. With no query it returns the closed category page of 20 categories (a 21st is reachable only by text search), so categories are effectively complete; tags and treatment types appear only for a text query and are ranked by Fresha's own autocomplete, so treat them as a discovered set rather than a complete catalogue and page with next_start while has_next_page is true. Use words from a treatment name such as nail, haircut or massage. Call this before a filtered fresha_search_venues request instead of guessing an id, because a well-formed id Fresha does not know returns zero results with no error.

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_taxonomy"
  }
}

Input Schema

Name	Required	Description
`first`	No	Nodes per page, default 200 and maximum 200 (the gateway's own ceiling).
`query`	No	Optional taxonomy search text. Empty returns the closed category page (20 values plus a text-only 21st); a text query returns the categories, tags and treatment types Fresha's autocomplete ranks for that word. Use words from a treatment name, e.g. nail, haircut, massage.
`start`	No	Zero-based offset into the ranked node list, default 0. Pass next_start from the previous page while has_next_page is true.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Well beyond the readOnlyHint/openWorldHint annotations, it discloses that the no-query page is a closed set of 20 categories (with a 21st reachable only by text search), that tags and treatment types appear only for a text query and are ranked by Fresha's autocomplete rather than being a complete catalogue, and how to page with next_start while has_next_page. That ranking/pagination incompleteness disclosure is exactly the kind of behavior an agent cannot infer from structured fields.

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?

A single dense paragraph with the purpose front-loaded and no filler sentences; each clause carries information (id forms, closed category page, autocomplete ranking, paging). It loses a point because the query/pagination behavior is restated almost verbatim in the schema property descriptions, making parts of the body redundant.

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 zero-required-parameter lookup tool with an output schema, the description covers everything an agent needs: what it returns, id syntax, catalogue completeness caveats, paging, and why to call it before the venue search. Nothing material is left to inference.

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, but the description adds semantic meaning the schema only restates: what an empty query returns versus a text query, what kind of vocabulary is productive in `query`, and that paging is driven by next_start/has_next_page. The main gap is that these points are duplicated in the schema descriptions rather than adding genuinely new detail.

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?

States a specific verb and resource ('List Fresha's treatment taxonomy') and immediately names the concrete outcome: the ids that fresha_search_venues accepts as treatment_category_id, treatment_tag_id and treatment_type_id. It also distinguishes the three node kinds and their id forms, so an agent can tell exactly what this tool produces versus the sibling venue-search tool.

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?

Explicitly prescribes the workflow: 'Call this before a filtered fresha_search_venues request instead of guessing an id', and gives the reason (unknown well-formed ids return zero results with no error). It also tells the agent what query text to supply ('words from a treatment name such as nail, haircut or massage').

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

All Crawlora MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?