Crawlora MCP

booksy_treatment_hints

Read-only

Discover Booksy treatment ids for a search text and return the matching treatments (integer id, name, slug, type) alongside the suggested businesses (id, name, slug, web path token, address), with counts per kind. This is the discovery step for the treatment parameter of booksy_businesses and the only treatment-id surface the Booksy app API exposes. It is query-driven, not a taxonomy: query_driven is always true and a treatment id that no query surfaces can still exist, so do not treat the returned set as complete. Seed it with the service you want (haircut, braids, nails, massage). A query that matches nothing returns an empty suggestions array rather than an error; a blank query is rejected.

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": {
      "query": "<query>"
    },
    "name": "booksy_treatment_hints"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes	Required search text that seeds the hint lookup, for example haircut, braids or nails. The upstream rejects a blank value. Hints are query-driven: they are not a complete treatment taxonomy.
`country`	No	Optional Booksy market, one of the 18 country hosts that serve this API. Defaults to us.

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?

Beyond readOnlyHint/openWorldHint it discloses concrete runtime behavior: a no-match query yields an empty suggestions array rather than an error, a blank query is rejected upstream, and results are query-driven rather than an exhaustive taxonomy. Those are exactly the failure modes an agent would otherwise have to discover by trial.

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-loaded with purpose and return shape, then usage routing, then behavioral caveats — a logical order. It is dense but nearly every clause carries information; the parenthetical field listings are the only mildly redundant part since an output schema exists.

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

Completeness4/5

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

Output schema exists so return values needn't be re-explained, and the description nonetheless summarizes them. Given two required-ish params, a read-only open-world read, and the query-driven caveat, this is complete enough for correct invocation; the only omission is any mention of the optional country parameter.

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 the baseline is a 3, but here the description adds real meaning beyond the schema: it warns that the returned set is not a complete taxonomy, explains what the query seeds, and clarifies the empty-result and blank-query behaviors that shape how the agent should phrase the query.

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: 'Discover Booksy treatment ids for a search text' and enumerates the returned shape (id, name, slug, type plus suggested businesses). It also distinguishes itself from booksy_businesses by naming itself 'the discovery step for the treatment parameter' and 'the only treatment-id surface the Booksy app API exposes'.

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 tells the agent when to reach for this tool (to obtain a treatment id for booksy_businesses) and gives seeding guidance ('haircut, braids, nails, massage'). It also sets a guardrail against misuse: 'do not treat the returned set as complete' because ids can exist that no query surfaces.

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?