Fresha MCP Server and API by Cotlet

List team members

list_team_members

Read-onlyIdempotent

Team members with role, contact, services they do and whether they take bookings. Lists the team as Team members shows it: name, email, mobile, role (owner, manager, basic), job title, whether they take bookings and online bookings, the services assigned to them, their primary location (location_id) and every location they work at (location_ids). Also lists the business's locations. Use team_member_id in the calendar tools, with location_id set to one of that member's location_ids when the business has several.

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": "list_team_members"
  }
}

Input Schema

Name	Required	Description	Default
`location_id`	No	Only team members who work at this location.
`include_former`	No	Also team members who left. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / location_id

Added value: +{
+  "description": "Only team members who work at this location.",
+  "pattern": "^[0-9]+$",
+  "type": "string"
+}

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 establish read-only, idempotent, non-destructive behavior, so the description is not burdened with safety disclosure. It adds value by describing the returned fields and how the returned IDs should be reused in calendar tools, though it omits pagination, ordering, and explicit former-member behavior.

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?

The description is front-loaded with what the tool returns and ends with practical integration guidance. It is dense but mostly earns its space; the first clause and the subsequent field list repeat the same idea slightly, keeping it from a 5.

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 does the work of enumerating return fields and explaining downstream ID usage. It is nearly complete for a read-only listing tool, though it could mention include_former behavior and whether results are paginated or ordered.

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. The description still adds useful meaning by explaining that location_id is the member's primary location and that location_ids lists every location they work at, clarifying how the input filter relates to returned data.

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?

The description states a specific verb and resource: listing team members, and enumerates the exact fields returned (name, email, role, services, locations, bookings). It is clearly distinguishable from siblings such as list_clients or list_services because the resource is unambiguous.

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?

It gives clear downstream usage guidance: use team_member_id in calendar tools, and set location_id to one of the member's location_ids when the business has multiple locations. It does not explicitly name alternatives or when not to use this tool, so it stops short of a 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.