StudioVector: Chat with your Mindbody

Find clients likely to book a class

find_likely_attendees

Read-onlyIdempotent

Finds the clients most likely to book a class, to fill open spots or target a promotion. Give an upcoming classId (from find_classes) or a className such as "yoga". Reads who booked the same class type in past classes (most recent first), scores each client 0-100 on how often and how recently they came and how many bookings they kept, and, for a classId, whether they come on the same weekday and time and with the same instructor. Returns the top clients with contact details and active memberships; clients already booked into the class are left out. Mindbody calls: 1 for the class (or 1-3 to look up class type names), 1 per 200 past classes, 1 per past class with bookings (up to maxClasses), then 1 per 20 clients returned plus 1 for memberships (at most 112). Rosters need a staff token that may view class rosters; when Mindbody returns none, the result says so instead of ranking.

Input Schema

Name	Required	Description
`limit`	No	Clients to return, 1-50 (default 20).
`match`	No	Which past classes count: classType (default) = the same class type; sessionType = the same session type; program = any class in the same program (broadest).
`siteId`	No	Site to call (SiteId header). Default -99.
`classId`	No	The class to fill (the "id" from find_classes). Its type, weekday, time and instructor shape the ranking.
`className`	No	Instead of classId: a class type name or part of one, e.g. "yoga" (every class type whose name contains it).
`maxClasses`	No	Most recent past classes with bookings whose rosters are read, 1-100 (default 40; 1 Mindbody call each).
`locationIds`	No	Only count past classes at these locations.
`lookbackDays`	No	Days of history to read, 14-180 (default 90).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the supplied annotations by disclosing the scoring rubric (0-100 on frequency, recency, kept bookings, plus weekday/time/instructor matching for a classId), the ordering of history read, and the exclusion of already-booked clients. It also documents cost and limits (1 call per 200 past classes, up to maxClasses, at most 112 calls) and the auth requirement (staff token that may view class rosters) with the fallback behavior when rosters are unavailable. That is exactly the context annotations cannot carry.

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-loads the purpose, then input modes, then ranking behavior, then cost, then auth constraint – a logical progression. It is a dense block of prose with no line breaks, and the call-cost sentence is long, 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?

With no output schema, the description still covers what is returned (top clients with contact details and active memberships), the ordering, the exclusion rule, and the degraded-but-informative response when rosters are inaccessible. For an 8-parameter read tool that fans out into many upstream calls, this is complete.

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, but the description adds real meaning: it ties classId to find_classes, explains that className matches any class type containing the substring, and clarifies that maxClasses drives per-class call cost. The interplay between match mode and ranking inputs (weekday/time/instructor apply only for classId) is a genuine semantic addition.

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 ('Finds the clients most likely to book a class') plus the intended outcome ('fill open spots or target a promotion'), which distinguishes it from lookup siblings like find_classes and find_client. An agent can tell this is a ranked-prospect tool, not a roster or a profile lookup.

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?

Gives explicit selection guidance between the two input modes (classId from find_classes vs className like "yoga") and states an exclusion rule (already-booked clients are dropped). It does not name competing siblings such as clients_at_risk or enrollment_fill, so it stops short of full when-not guidance.

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

All StudioVector: Chat with your Mindbody 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?