Fresha MCP Server and API by Cotlet

Find available slots

find_available_slots

Read-onlyIdempotent

Free start times for one or more services with a team member, day by day. Asks the calendar for free start times as New appointment does, for the services done one after another, with one team member at one location, over up to 14 days. Give service_ids (service_id from list_services), or pricing_level_ids to pick a pricing level other than a service's first. In a business with several locations, pass location_id and a team member who works there (location_ids in list_team_members); without it the team member's primary location is used. Times are wall clock in the business's time zone; closed days have no times. Book a time with create_appointment, with the same team member and location.

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": {
      "date": "<date>"
    },
    "name": "find_available_slots"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	First day to search.
`days`	No	Days to search. Default: 1.
`location_id`	No	Location to book at, from list_team_members. Default: the team member's primary location, else the business's first location.
`service_ids`	No	service_id values from list_services (not pricing_level_id), done one after another in this order. Use the same location_id as in list_services.
`team_member_id`	No	Team member to book. Default: the first at the location who takes bookings.
`pricing_level_ids`	No	Instead of service_ids: pricing_level_id values from list_services, to book a pricing level other than a service's first one. Done one after another in this order.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 31, 2026

addedInput schema / properties / location_id

Added value: +{
+  "description": "Location to book at, from list_team_members. Default: the team member's primary location, else the business's first location.",
+  "pattern": "^[0-9]+$",
+  "type": "string"
+}

addedInput schema / properties / pricing_level_ids

Added value: +{
+  "description": "Instead of service_ids: pricing_level_id values from list_services, to book a pricing level other than a service's first one. Done one after another in this order.",
+  "items": {
+    "pattern": "^[0-9]+$",
+    "type": "string"
+  },
+  "maxItems": 5,
+  "minItems": 1,
+  "type": "array"
+}

changedInput schema / properties / service_ids / description

Previous value: -"Service ids from list_services, done one after another in this order."New value: +"service_id values from list_services (not pricing_level_id), done one after another in this order. Use the same location_id as in list_services."

changedInput schema / properties / team_member_id / description

Previous value: -"Team member to book. Default: the first who takes bookings."New value: +"Team member to book. Default: the first at the location who takes bookings."

changedInput schema / required

Previous value: -[
-  "service_ids",
-  "date"
-]New value: +[
+  "date"
+]

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description is free to add operational context — and it does: a 14-day search ceiling, wall-clock times in the business time zone, 'closed days have no times', and fallback behavior for unset location/team member. The return shape (how slots are grouped by day) is only implied.

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, then parameter guidance, then next step — a sensible order. The phrase 'Asks the calendar for free start times as New appointment does' is a slightly muddled cross-reference, but otherwise no wasted sentences.

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?

With six parameters and no output schema, the description does the needed work: it explains scope, defaults, the time zone of returned times, and the absence of times on closed days. A note on whether slots are grouped per day or returned flat would close the last gap.

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 baseline is 3; the description earns extra credit by documenting relationships the schema cannot express — that pricing_level_ids is an alternative to service_ids ('Instead of...'), and that location_id must match a location the chosen team member works at, otherwise the primary location is used.

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?

Specific verb+resource: 'Free start times for one or more services with a team member, day by day.' It also scopes the search (one team member, one location, up to 14 days), which cleanly separates it from list_appointments and create_appointment.

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?

Explicitly routes between service_ids and pricing_level_ids, states the multi-location condition for location_id, and names the follow-up tool ('Book a time with create_appointment, with the same team member and location'). It lacks an explicit when-not-to-use case versus list_appointments, keeping it at 4 rather than 5.

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

All Fresha MCP Server and API by Cotlet 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.