Fresha MCP Server and API by Cotlet

Create appointment

create_appointment

Destructive

Book an appointment for a client: services, team member and start time. Books the services one after another from start_at with one team member at one location, as New appointment in the calendar does, at each service's catalogue price. 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. Fresha may send the client a booking confirmation by their notification settings (get_client), so this can reach the client. Find free times with find_available_slots first: Fresha books over other appointments and returns its warnings. By default you confirm each call; you can switch that off for this tool. Waits for the owner's approval.

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": {
      "start_at": "<start_at>"
    },
    "name": "create_appointment"
  }
}

Input Schema

Name	Required	Description
`start_at`	Yes	Start, ISO 8601: 2026-11-03T14:30 is wall clock in the business's time zone; with an offset (2026-11-03T14:30:00+01:00) it is converted.
`client_id`	No	Client from list_clients. Without it: a walk-in.
`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. 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. Default: the first who takes bookings."New value: +"Team member. Default: the first at the location who takes bookings."

changedInput schema / required

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

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: it discloses overbooking risk ("Fresha books over other appointments and returns its warnings"), that the client may receive a real notification, that each call is confirmed by default, and that the tool waits for owner approval. These are exactly the consequences an agent needs before a destructive, non-idempotent write, and they are consistent with destructiveHint=true.

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?

Dense and front-loaded: purpose, sequencing, then identifier sourcing, then side effects. A couple of clauses (the parenthetical about "as New appointment in the calendar does") are wordier than necessary, but no sentence is filler.

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 6-parameter destructive write with no output schema, the description covers sequencing, defaults, identifier provenance, side effects, and even the return signal ("returns its warnings"). Nothing material is left for the agent to guess.

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 nonetheless adds cross-parameter meaning by framing service_ids and pricing_level_ids as alternatives and by explaining the location_id default chain. It does not clarify the maxItems=5 limit or ordering interaction between the two array parameters beyond "one after another".

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 ("Book an appointment for a client") and immediately enumerates the three core inputs. It is clearly distinguished from siblings like reschedule_appointment or cancel_appointment by describing creation semantics ("as New appointment in the calendar does").

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 routes the agent: "Find free times with find_available_slots first", "Give service_ids ... or pricing_level_ids", and "In a business with several locations, pass location_id". It also names the prerequisite lookups (list_services, list_team_members, get_client) that supply each identifier, so the ordering of calls is inferable.

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.