Skip to main content
Glama
Sign In

Fresha MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Get client

get_client
Read-onlyIdempotent

One client: contact, notification settings, booking stats, upcoming appointments, notes. Reads the client profile as the client's page shows it: name, email, mobile, gender, birthday, whether Fresha sends them appointment messages and marketing by email, SMS and WhatsApp, booking and sales totals, the next 10 appointments and the latest 10 notes.

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": {
      "client_id": "<client_id>"
    },
    "name": "get_client"
  }
}

Input Schema

NameRequiredDescriptionDefault
client_idYesClient id from list_clients.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the description need not restate safety. It does add real behavioral value beyond annotations: the truncation limits ('next 10 appointments', 'latest 10 notes'), the fact that this mirrors the client's page view, and the notification channel dimensions (email/SMS/WhatsApp, appointment vs marketing).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead sentence is well front-loaded, but the second sentence re-enumerates many of the same concepts at greater length, producing overlap ('contact... notification settings... booking stats, upcoming appointments, notes' then re-listed in detail). It earns most of its length through the truncation and channel details, but the duplication costs clarity.

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 no output schema, the description must convey the return shape, and it does so concretely, including which fields are present and the 10-item caps on appointments and notes. An agent can decide whether this tool answers its question without a trial call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and client_id already documents the pattern and the 'from list_clients' source, so the schema does the heavy lifting. The description adds nothing about the single parameter, which is the expected baseline of 3 for a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource, 'One client: contact, notification settings, booking stats, upcoming appointments, notes', making clear this is a single-record fetch. It implicitly contrasts with list_clients through the singular scope, but never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the second sentence describes what is returned, from which an agent can infer 'call this when you already have a client_id'. There is no explicit statement of when to use this versus list_clients or get_appointment, and no prerequisites (e.g. id must come from list_clients) even though the schema carries that hint.

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 toolsInspect
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