StudioVector: Chat with your Mindbody

Class attendance and fill-rate summary

class_attendance_summary

Read-onlyIdempotent

Answers class attendance questions in one call: how full classes were (or are booked), which class types, teachers, locations and times fill best, and how many booked clients signed in. Reads every class in a date range, past or upcoming (up to 92 days), and returns totals (classes, canceled, capacity, booked, waitlisted, fill rate, full and empty classes, average booked) and breakdowns by class type, teacher (with substitute classes), location and time slot, plus optional by weekday, by day or week, and the fullest and emptiest classes, and a comparison with the previous period. Canceled classes are counted on their own and left out of every rate. Fill rate is booked / capacity, over classes that have a capacity. For classes that have ended, signedIn, signInRatePct and notSignedIn (booked but not signed in: no-shows and unchecked bookings) are reported only when the studio records sign-ins, over every program; for the not-signed-in rate over only the programs that record sign-ins, use class_mix. Filters by location, teacher, program or class type IDs. Use this instead of find_classes for attendance and fill-rate questions. Mindbody calls: 1 per 200 classes, doubled with compareToPrevious (at most 50).

Input Schema

Name	Required	Description
`top`	No	Rows per ranked breakdown, and classes in fullest and emptiest, 1-25 (default 10). The rest of a breakdown is folded into one "other" row.
`range`	No	Date range (default last_30_days). The last_* ranges and month_to_date end today; next_* start today. Use startDate/endDate for other ranges.
`siteId`	No	Site to call (SiteId header). Default -99.
`endDate`	No	Last day, inclusive (default today). At most 92 days after startDate.
`include`	No	Breakdowns besides totals (default byClass, byStaff, byLocation, byTimeSlot). byTimeSlot is weekday and start hour, busiest first; byWeekday lists Monday to Sunday; byPeriod is by day up to 31 days, else by week; fullest and emptiest list individual classes.
`staffIds`	No	Only classes taught by these staff members (get_staff).
`startDate`	No	First day, e.g. 2026-09-01 (business-local). Default: 30 days ending endDate.
`programIds`	No	Only classes in these programs (get_programs).
`locationIds`	No	Only classes at these locations (get_locations).
`compareToPrevious`	No	Also total the previous period (doubles the classes calls) and report the change: classes and bookings in percent, fill and sign-in rates in points. Whole calendar months compare with the previous whole months, other ranges with the same number of days just before.
`classDescriptionIds`	No	Only these class types (get_class_descriptions).

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?

Beyond readOnly/idempotent annotations, it discloses non-obvious rules: canceled classes are counted separately and excluded from all rates, fill rate is booked/capacity over classes with capacity, sign-in fields appear only for ended classes at studios that record sign-ins, and Mindbody call cost is 1 per 200 classes (doubled with compareToPrevious, max 50).

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 the question it answers and the outputs, then definitions, then routing and cost. It is one dense run-on paragraph with some redundancy (filters repeated as 'location, teacher, program or class type IDs'), but nearly every clause carries substance.

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 an 11-parameter, no-output-schema aggregate tool, the description supplies the return contents, rate definitions, edge cases (no capacity, canceled classes, sign-in availability) and cost model. An agent has enough to call it correctly and interpret results without an output schema.

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%, so the schema already documents every parameter including range, include, top and compareToPrevious semantics. The description only restates filter dimensions and the 92-day / comparison behaviors that the schema already spells out, adding little marginal meaning.

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 framing ('Answers class attendance questions in one call') and enumerates the exact metrics returned (fill rate, booked, waitlisted, signed in). It explicitly positions itself against find_classes and class_mix, so an agent can distinguish it from siblings without inspecting schemas.

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?

Gives explicit routing: 'Use this instead of find_classes for attendance and fill-rate questions' and points to class_mix for the not-signed-in rate over only sign-in-recording programs. It also states the date-range and call-budget constraints that govern when the tool is practical.

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?