Read Mindbody classes, schedules, clients, staff and sales; book clients and appointments.
Scored across 20 tools
The add/get/list/update split plus resource-specific nouns makes most tools clearly distinct, and descriptions actively disambiguate tricky pairs (list_classes = occurrences vs list_class_schedules = templates vs get_class_visits = roster; list_services = pricing options vs list_session_types = bookable kinds). Minor overlap remains between mindbody_list_staff (can find available staff for a session type) and mindbody_list_bookable_items, and between the three visit-listing tools, but descriptions resolve these.
All 20 tools follow a uniform mindbody_<verb>_<noun> snake_case pattern with a small, predictable verb set (list, get, add, update). The only wart is the get-vs-list split for reads (get_class_visits, get_client_account_balances sit alongside list_clients, list_sales) and list_bookable_items acting as a finder rather than a plain listing, but these are semantically motivated and readable.
Twenty tools is on the heavy side, but the server spans a wide domain (clients, appointments, classes, schedules, sales, staff, site config), so each tool maps to a distinct API endpoint and resource. Nothing looks redundant or padded for the scope covered.
Read coverage is strong (clients, visits, classes, schedules, services, sales, staff, locations, sites, session types) and core booking flows exist, but there are notable write-side gaps: no cancel/remove appointment, no removal of a client from a class (explicitly punted to the front desk), and no way to create or edit class schedules, classes, or process checkout sales. These dead ends will block cleanup and checkout workflows for an agent.
Book an appointment for a client with a staff member at a location. Find a slot first with mindbody_list_bookable_items. No card is charged; apply_payment (Mindbody's default is true) only applies a pricing option already on the client's account. Pass test: true to validate only. Requires a staff user token. Mindbody: POST /appointment/addappointment.
| Name | Required | Description | Default |
|---|---|---|---|
| test | No | When true, Mindbody validates the request but commits nothing. Use it to dry-run a write. | |
| notes | No | General notes for the appointment. | |
| duration | No | Override the default duration, in minutes. | |
| staff_id | Yes | The staff member delivering the appointment. | |
| client_id | Yes | The client's ID (RSSID — a string, as configured by the business; see mindbody_list_clients). | |
| send_email | No | Send the site's automatic email. | |
| is_waitlist | No | Add to the appointment waiting list instead. | |
| location_id | Yes | The location id. | |
| resource_ids | No | Resource (room/equipment) ids to attach. | |
| apply_payment | No | Apply a pricing option already on the client's account (Mindbody default: true). | |
| end_date_time | No | End, ISO 8601. Default: start + the default duration. | |
| session_type_id | Yes | The session type id. | |
| staff_requested | No | The client asked for this staff member specifically. | |
| start_date_time | Yes | Start, ISO 8601 (e.g. 2026-10-01T14:00:00). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructiveHint annotation: states that no card is charged, that apply_payment only consumes a pricing option already on the client's account, that test: true rolls the write back, and that a staff user token is required. Auth requirements and the dry-run escape hatch are exactly the kind of behavioral context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then prerequisite, then the payment/dry-run caveats and auth note. Dense but every sentence carries information except the trailing 'Mindbody: POST /appointment/addappointment' endpoint reference, which is implementation detail an agent does not act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter mutation with no output schema, the description supplies what is missing elsewhere: the required staff token, the prerequisite slot lookup, the payment behavior, and the validation-only mode. An agent has everything needed to call it correctly or safely decline to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 14 parameters and the baseline would be 3. The description nonetheless adds semantics the schema lacks for the highest-risk flag, clarifying that 'No card is charged' under apply_payment and that test:true commits nothing, which materially changes how an agent sets those fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (book) and resource (appointment) and names the three participating entities: client, staff member, location. It also points to the sibling mindbody_list_bookable_items as the slot-finding precursor, so an agent can separate this write tool from the list/lookup siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes the expected workflow: 'Find a slot first with mindbody_list_bookable_items,' and offers the dry-run path via test: true. It gives clear positive context but no explicit 'when not to use' (e.g. rescheduling an existing appointment, which would belong to mindbody_update_appointment).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new client record (first and last name required; the site may require more — Mindbody reports which). No card or billing data is accepted. Pass test: true to validate only. Mindbody: POST /client/addclient.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City. | |
| test | No | When true, Mindbody validates the request but commits nothing. Use it to dry-run a write. | |
| No | Email address. | ||
| state | No | State / region. | |
| gender | No | Gender, as configured at the site (see the site's genders). | |
| country | No | Country. | |
| last_name | Yes | Last name. | |
| birth_date | No | Date of birth, ISO 8601 (e.g. 1990-04-12). | |
| first_name | Yes | First name. | |
| home_phone | No | Home phone number. | |
| work_phone | No | Work phone number. | |
| is_prospect | No | Mark the client as a prospect (only if the site allows prospects). | |
| middle_name | No | Middle name. | |
| postal_code | No | Postal code. | |
| referred_by | No | How the client was referred (one of the site's referral types). | |
| mobile_phone | No | Mobile phone number. | |
| address_line_1 | No | Street address, line 1. | |
| address_line_2 | No | Street address, line 2. | |
| send_account_emails | No | Opt in/out of account notification emails. | |
| send_schedule_emails | No | Opt in/out of schedule notification emails. | |
| send_promotional_emails | No | Opt in/out of promotional emails. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry only destructiveHint:true, so the description does the heavy lifting and does it well: it discloses a data-scope prohibition (no card/billing), server-side validation behavior (the site may require additional fields and Mindbody reports which), and a safe validation path (test:true commits nothing). This is real operational context, not restatement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight clauses, front-loaded with purpose and requirements, then constraints and dry-run guidance. No filler, and the Mindbody endpoint is a useful trailing detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 21-parameter mutation with no output schema, the description covers the critical unknowns: required fields, extra server-side requirements, the disallowed data class, and dry-run support. It does not describe what a successful creation returns (e.g., new client ID), which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 21 parameters are already documented in the schema. The description reinforces the required names and the test flag but adds no syntax, format, or edge-case detail beyond what the schema already says; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a new client record') and immediately bounds the scope by what data it will not take ('No card or billing data is accepted'), which cleanly separates it from mindbody_update_client and mindbody_add_client_to_class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context: minimum required fields, the fact that the site may demand more, and how to dry-run via test:true. It stops short of explicitly naming an alternative tool or stating when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a client into a class (or onto its waiting list). Does not take payment: by default no pricing option is required; set require_payment to insist the client has a usable one on account. Undo from the Mindbody front desk. Pass test: true to validate only. Mindbody: POST /class/addclienttoclass.
| Name | Required | Description | Default |
|---|---|---|---|
| test | No | When true, Mindbody validates the request but commits nothing. Use it to dry-run a write. | |
| class_id | Yes | The class id (from mindbody_list_classes). | |
| waitlist | No | Add to the class waiting list instead of the class. | |
| client_id | Yes | The client's ID (RSSID — a string, as configured by the business; see mindbody_list_clients). | |
| send_email | No | Send the site's booking confirmation email. | |
| require_payment | No | Require an active, usable pricing option on the client's account. | |
| client_service_id | No | The id of the pricing option already on the client's account to use for this booking. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint=true; the description adds the critical operational fact that this write takes no payment by default, that it can be dry-run via test:true, and that reversal is done 'from the Mindbody front desk' rather than through the API — a genuinely useful irreversibility signal. It omits auth/permission requirements and any rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the primary action and scope, then payment semantics, then undo/dry-run behavior. No filler; the endpoint reference is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no output schema, it covers the key unknowns an agent needs: payment defaults, dry-run, and the absence of an API-side undo. Remaining gaps (auth requirements, response shape, behavior when the class is full) are modest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds default-state semantics not present in the schema (no pricing option needed unless require_payment is set) and frames test:true as a dry run. It does not explain waitlist/send_email/client_service_id interactions beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Book a client into a class') and immediately extends scope to the waiting list. It is clearly distinguishable from siblings like mindbody_add_appointment and mindbody_add_client.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the default payment behavior, how to opt into requiring a pricing option, and that test:true performs a dry run. It stops short of explicitly contrasting when to use this versus mindbody_add_appointment, so it is clear context without full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one class with its visits — the roster of clients booked into it, with sign-in / late-cancel status. Mindbody: GET /class/classvisits.
| Name | Required | Description | Default |
|---|---|---|---|
| class_id | Yes | The class id (from mindbody_list_classes). | |
| last_modified_date | No | Only visits modified on or after this date — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful payload context — the result is a roster of clients with sign-in/late-cancel status — and pins the upstream API (GET /class/classvisits), but says nothing about pagination, volume limits, or auth requirements for a potentially large roster.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the resource and immediately followed by a clarifying gloss and the API mapping. Nothing is redundant and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 a fair job of characterizing the return (roster plus sign-in/late-cancel status) and the filtering semantics via the schema's last_modified_date. It is close to complete for a two-parameter read tool, missing only pagination/bounding behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (class_id, last_modified_date) are already fully documented with format examples and provenance. The description contributes no additional parameter meaning, which is the baseline 3 case when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one class with its visits') and disambiguates the term by defining visits as 'the roster of clients booked into it, with sign-in / late-cancel status.' It effectively separates itself from the per-client sibling (mindbody_list_client_visits) by scoping to a single class, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no alternatives are mentioned. The only prerequisite signal ('from mindbody_list_classes') lives in the schema, not the description, so an agent reading the description alone gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the account balance for one or more clients (what they owe or hold in credit), optionally as of a date. Mindbody: GET /client/clientaccountbalances.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| class_id | No | Balance relative to this class/event id. | |
| client_ids | Yes | The client ids to get balances for. | |
| balance_date | No | Balance as of this date (default today) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already covers the safety profile. The description adds real context by clarifying that a balance can be an amount owed OR a credit held, which affects how results are interpreted, but it says nothing about auth requirements, rate limits, or pagination behavior despite limit/offset parameters existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the semantic clarification front-loaded before the endpoint reference. The trailing API-endpoint note is somewhat auxiliary but conventional and short; nothing is wasted or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries more of the return-value burden, and it only gestures at the response ('what they owe or hold in credit') without naming fields or explaining the limit/offset paging that the API supports. Adequate for a read-only getter with full annotation coverage, but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented, including balance_date's ISO 8601 format and default. The description's 'optionally as of a date' merely restates balance_date and adds no syntax or constraint detail beyond the schema, which is the baseline-3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (Get) and resource (client account balances), and the parenthetical 'what they owe or hold in credit' defines what 'balance' means so the agent isn't guessing. The endpoint mapping (GET /client/clientaccountbalances) and the client-scoped framing clearly distinguish it from sibling list_* tools like list_client_memberships and list_client_visits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one or more clients ... optionally as of a date' implies the calling context (batch balance lookup, optional point-in-time), but there is no explicit when-to-use/when-not guidance and no named alternative among the many client/billing siblings. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find appointment availability — which staff can deliver the given session types, where, and in which time windows. Use before mindbody_add_appointment. Mindbody: GET /appointment/bookableitems.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| end_date | No | End of the range (default start_date) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| staff_ids | No | Only these staff ids (omit for all staff). | |
| start_date | No | Start of the range (default today) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| location_ids | No | Only at these location ids. | |
| appointment_id | No | Exclude this existing appointment (useful when rescheduling). | |
| session_type_ids | Yes | Session type ids to find availability for (see mindbody_list_session_types). | |
| ignore_default_session_length | No | Also return availabilities that differ from the session type's default length. | |
| include_resource_availability | No | Include resource (room/equipment) availability. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description reinforces this by naming the underlying GET endpoint. It adds no behavioral context beyond that – no pagination behavior, result caps, or auth requirements. Adequate but thin given annotations do the heavy lifting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the core purpose and return shape front-loaded before the sequencing hint. The trailing 'Mindbody: GET /appointment/bookableitems' is mildly redundant but useful for API mapping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description reasonably signals the return shape (staff, location, time windows). It does not describe pagination behavior or how results are grouped, which an agent must infer from the schema, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters are already documented in the schema, including defaults, formats, and semantics. The description only gestures at the filter dimensions (staff, session types, location, time) without adding format or interplay details beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Find') plus resource ('appointment availability') with an explicit enumeration of what is returned – staff, location, and time windows for the given session types. It distinguishes the tool from mindbody_add_appointment by naming the sequencing relationship, though it does not explicitly contrast with mindbody_list_staff_appointments or mindbody_list_session_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing guidance: 'Use before mindbody_add_appointment.' It also points to mindbody_list_session_types for obtaining session type ids. No when-not guidance is given (e.g., that this is not for listing already-booked appointments, which is a sibling's job).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List scheduled class occurrences in a date range — time, class description, teacher, location, capacity, booked/waitlist counts and cancellation status. Mindbody: GET /class/classes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| class_ids | No | Only these class ids. | |
| client_id | No | View the list as this client (may reveal client-specific pricing). | |
| staff_ids | No | Only taught by these staff ids. | |
| program_ids | No | Only in these program ids. | |
| location_ids | No | Only at these location ids. | |
| end_date_time | No | End of the range (default today; compares dates, not times) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| start_date_time | No | Start of the range (default today) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| session_type_ids | No | Only these session type ids. | |
| class_schedule_ids | No | Only classes from these class schedule ids. | |
| last_modified_date | No | Only classes modified on or after this date — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| class_description_ids | No | Only these class description ids. | |
| hide_canceled_classes | No | Drop canceled classes from the response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes the safety profile, so the description's job is to add context — and it does, by disclosing the returned dimensions (teacher, location, capacity, booked/waitlist counts, cancellation status) and the underlying GET /class/classes endpoint. It stops short of noting pagination flow or the cost of client_id pricing lookups.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads scope and return contents, the second records the upstream endpoint. Given there is no output schema, the field enumeration earns its space rather than being padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, zero-required tool with no output schema, the description covers scope and response shape adequately, and the schema carries the per-filter semantics. It omits any mention of paging behavior or result-set size expectations, which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with per-parameter semantics, defaults and formats (ISO 8601 examples, 1-200 limit) already documented in the schema. The description adds only the aggregate notion of a date range, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List scheduled class occurrences in a date range') and enumerates the payload the agent will receive, which is far more informative than the title alone. It never names the sibling tools (list_class_schedules, get_class_visits) that an agent could confuse with it, so differentiation is implicit in 'occurrences' rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The date-range framing and the field list imply the use case (browsing scheduled sessions with booking counts), but there is no explicit when-to-use / when-not-to-use statement and no routing to alternatives like list_class_schedules for templates or get_class_visits for attendance. Usage is inferable but left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recurring class schedules (the templates that generate class occurrences) — days, times, teacher, location and date span. Mindbody: GET /class/classschedules.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| end_date | No | Only schedules active on or before this day (default start_date) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| staff_ids | No | Only taught by these staff ids. | |
| start_date | No | Only schedules active on or after this day (default today) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| program_ids | No | Only in these program ids. | |
| location_ids | No | Only at these location ids. | |
| session_type_ids | No | Only these session type ids. | |
| class_schedule_ids | No | Only these class schedule ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context by mapping to the underlying endpoint (GET /class/classschedules) and clarifying that results are templates rather than occurrences, but says nothing about pagination behavior, result volume, or default date-window semantics beyond what the schema carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses with the resource definition front-loaded and the endpoint reference appended as compact provenance. No filler sentences, nothing that fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-required-parameter list tool with full schema coverage and no output schema, this is close to sufficient: it identifies the resource, distinguishes it from occurrences, and hints at returned fields. It stops short of noting that results are paged/default-limited, which is the only meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 9 parameters, including defaults and range notes, so the schema carries the parameter burden. The description's field list (days, times, teacher, location) loosely corresponds to filterable dimensions but adds no syntax, id-format, or combining rules beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List recurring class schedules') and immediately disambiguates the resource as 'the templates that generate class occurrences', which is exactly the distinction an agent needs against sibling tools like mindbody_list_classes. It also enumerates what a schedule contains (days, times, teacher, location, date span).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use/when-not statement and no sibling tool is named as an alternative. The template-vs-occurrence framing implies the right context (use this for recurring templates, not individual classes), but the agent must infer that routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a client's active memberships (auto-renewing pricing options) with remaining counts and expiry. Mindbody: GET /client/activeclientmemberships.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| client_id | Yes | The client's ID (RSSID — a string, as configured by the business; see mindbody_list_clients). | |
| location_id | No | Only memberships usable at this location (not with cross_regional_lookup). | |
| cross_regional_lookup | No | Search up to ten associated sites in the region. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered externally. The description adds that results carry remaining counts and expiry, which is useful behavioral context, but says nothing about pagination behavior, the 'active-only' filter semantics, or regional lookup effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence plus an endpoint reference; the key scope, output contents and API path are front-loaded with no wasted prose. The endpoint citation is mildly redundant but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and no output schema, the description adequately covers scope and return contents (counts, expiry). Only minor gaps remain around pagination and filtering caveats, which the schema partly addresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters including client_id, limit, offset, location_id and cross_regional_lookup are already documented in the schema. The description contributes no additional parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List a client's active memberships') and even disambiguates what a membership is here ('auto-renewing pricing options'), which separates it from sibling list tools like mindbody_list_clients or mindbody_list_client_visits. It does not explicitly name an alternative, but 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus other client-oriented siblings, nor any prerequisites (e.g., needing a valid client_id/RSSID). Usage is only implied from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or fetch client records by name/email text or by client ids (max 20 ids) — contact details, status, alerts, home location. Requires a staff user token. Mindbody: GET /client/clients.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| client_ids | No | Only these client ids (max 20). | |
| is_prospect | No | true = only prospects; false = only non-prospects. | |
| search_text | No | Match against first name, last name and email. | |
| include_inactive | No | Include inactive clients (default false). | |
| last_modified_date | No | Only clients modified on or after this date — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint; the description adds the important behavioral constraint that a staff user token is required, which annotations do not cover. It still omits pagination behavior and default status filtering (include_inactive) beyond what the schema says.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence plus an endpoint reference; every clause earns its place and the two selection modes are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a fully documented schema and no output schema, the description covers purpose, modes, auth, and result fields. It stops short of describing pagination semantics or default inactive filtering, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description adds the max-20-ids constraint and clarifies that search covers name/email while ids are exclusive, reinforcing the two parameter paths. It does not explain limit/offset or date format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs (search/fetch) and resources (client records), enumerates the two selection modes (text vs ids), and lists returned fields, clearly distinguishing it from siblings like mindbody_get_client_account_balances or mindbody_list_client_visits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly presents the two usage modes (name/email text or client ids) with the 20-id cap, which tells the agent when each path applies. It lacks explicit when-not-to-use guidance versus siblings, but the two-mode framing is clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a client's past and scheduled visits (class and appointment attendance) in a date range, optionally only unpaid ones. Mindbody: GET /client/clientvisits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| order | No | Sort by date: desc = newest first. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| end_date | No | Only visits on or before this date (default today) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| client_id | Yes | The client's ID (RSSID — a string, as configured by the business; see mindbody_list_clients). | |
| start_date | No | Only visits on or after this date — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| unpaids_only | No | Only visits not yet paid for. | |
| cross_regional_lookup | No | Include visits at every site in the region. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read; the description adds that the call is a GET and that results span both past and scheduled visits, which is genuine context. It does not, however, disclose pagination behavior or result ordering beyond what the schema already documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core scoping information front-loaded; the Mindbody endpoint reference is mildly redundant but earns its place as an implementation anchor. No wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the return concept (visits in a date range) is clear and the annotations cover the safety profile. With all 8 parameters fully documented in the schema, the description supplies enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – every one of the 8 parameters is documented in the schema, including date formats, page sizing, and the RSSID note. The description only echoes the date-range and unpaids_only concepts, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (client's visits), plus scope: past and scheduled class/appointment attendance within a date range. An agent can tell this is client-scoped rather than class-scoped, though it never names the sibling mindbody_get_class_visits to sharpen the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'a client's past and scheduled visits' and the optional unpaid filter, but there is no explicit when-to-use guidance or routing away from alternatives like mindbody_get_class_visits or mindbody_get_client_account_balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the business's locations (studios / branches) with address, phone and amenities. Location ids are needed to book appointments. Mindbody: GET /site/locations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about what the records contain (address, phone, amenities), but says nothing about pagination behavior, result ordering, permissions, or an empty-result case, and no output schema exists to cover returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the resource and scope, then the downstream motivation. The trailing 'Mindbody: GET /site/locations' is mild implementation noise that does not serve an agent selecting the tool, keeping it just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, two-optional-parameter list tool with no output schema, the description says enough: what is listed, what fields come back, and why the ids matter. Only pagination behaviour and the locations-vs-sites distinction are left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with two optional paging parameters, so the schema already fully documents limit and offset including defaults and ranges. The description adds no parameter guidance at all, which is the correct baseline 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list the business's locations) and even enumerates the returned fields (address, phone, amenities) plus the downstream purpose of the ids. It does not, however, differentiate itself from the sibling mindbody_list_sites, which an agent could plausibly confuse with locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The line 'Location ids are needed to book appointments' supplies a workflow cue for why an agent would call this, which is more than nothing. But it names no alternatives (e.g. list_sites) and gives no when-not-to-use or prerequisite conditions, so usage remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List completed sales at the site in a date/time range — purchased items, payments and client. Read only. Mindbody: GET /sale/sales.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| sale_id | No | Only this sale id. | |
| payment_method_id | No | Only sales paid with this payment method id. | |
| end_sale_date_time | No | Only sales before this date/time — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| start_sale_date_time | No | Only sales after this date/time — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safety profile, and "Read only" restates it rather than adding information. Genuinely new context is limited to the "completed sales" filter and the returned field groups; pagination behavior, result caps, and site/auth scoping (the description says "at the site" but no site parameter exists) are undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with the resource and scope front-loaded, followed by a short read-only and endpoint note. Nothing is padded, though the "Mindbody: GET /sale/sales" trailer is developer trivia rather than agent-facing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates what comes back (purchased items, payments, client), which compensates for the missing return definition. The main gap is the unexplained "at the site" framing with no site parameter and no pagination note despite limit/offset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so limit, offset, sale_id, payment_method_id and the two date bounds are all self-documented. The description only paraphrases the date/time-range filter and adds no format, default, or interaction detail beyond the schema; baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource ("List completed sales") with explicit scope (site + date/time range) and a preview of the payload (purchased items, payments, client). It reads clearly against siblings like mindbody_list_client_visits or mindbody_list_services, though it never names those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the date/time-range scope but never stated as guidance: there is no when-to-use, when-not-to-use, or pointer to a sibling tool such as visit or membership listings. The agent must infer the appropriate context from the scope alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the pricing options (services — class packs, drop-ins, intro offers) for sale at the site, with price, online price, count and expiry. Read only. Mindbody: GET /sale/services.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| class_id | No | Only pricing options usable for this class id. | |
| staff_id | No | Show this staff member's per-staff pricing, if the site uses it. | |
| location_id | No | Compute TaxRate/TaxIncluded for this location (does not filter). | |
| program_ids | No | Only pricing options in these program ids. | |
| sell_online | No | Only pricing options sold online. | |
| service_ids | No | Only these pricing option ids. | |
| session_type_ids | No | Only pricing options for these session type ids. | |
| class_schedule_id | No | Only pricing options usable for this class schedule id. | |
| include_discontinued | No | Include discontinued pricing options. | |
| hide_related_programs | No | Omit pricing options of related programs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so 'Read only' in the description largely repeats structured data. It does add the upstream endpoint (GET /sale/services) and enumerates returned fields, which is modest extra context, but no auth requirements or pagination behavior are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences plus an endpoint tag, all front-loaded with the resource and purpose first. Nothing is padded, though the return-field list could be trimmed against the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 params and no output schema, the description partially compensates by naming returned fields (price, online price, count, expiry), but it omits pagination guidance despite limit/offset params and offers no routing between similarly named listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 12 parameters, so the schema already documents each filter's meaning (including caveats like location_id computing TaxRate rather than filtering). The description adds no parameter-level meaning beyond the schema, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (pricing options/services) and clarifies the domain terminology with the parenthetical 'class packs, drop-ins, intro offers', plus the return fields. It does not explicitly differentiate from close siblings like list_bookable_items or list_sales, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative routing is provided. 'For sale at the site' scopes the resource but gives no guidance on choosing this versus list_bookable_items or list_sales.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the session types (the bookable kinds of class or appointment, e.g. '60-min massage') used at the site. Session type ids drive appointment availability and booking. Mindbody: GET /site/sessiontypes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| online_only | No | Only session types bookable online. | |
| program_ids | No | Only session types in these program ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safe-read profile, and the description adds useful domain context that ids feed availability and booking. However it says nothing about pagination behavior, result volume, or auth/site-scoping requirements beyond what the annotations and schema already tell the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the definition and purpose come first, the underlying endpoint last. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and no output schema, the description covers what the resource is and the endpoint behind it. It stops short of describing filter interaction or result shape, but nothing essential to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, offset, online_only, and program_ids are all documented in the schema itself. The description adds no parameter-level detail (e.g., how program_ids interacts with online_only), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the session types') and immediately disambiguates the resource with a concrete definition ('the bookable kinds of class or appointment, e.g. 60-min massage'), which separates it from siblings like mindbody_list_services and mindbody_list_bookable_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains why the ids matter ('drive appointment availability and booking'), which implies when an agent would want them, but it never names an alternative tool or states when NOT to use this one. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Mindbody sites (businesses) your developer account can access, or details for specific site ids. A cheap way to confirm the API key works. Mindbody: GET /site/sites.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| site_ids | No | Only these site ids (returns more detail per site). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read. The description adds genuine context beyond that: results are scoped to the developer account's accessible sites, and passing site_ids returns more detail per site. Minor gaps remain around pagination/return shape, but the added behavioral detail is real.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, followed by the alternate mode, a usage hint, and the underlying endpoint. No filler; every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-required-param, read-only list tool with fully documented parameters, the description is nearly sufficient. Since no output schema exists, it does not describe what a site record contains, but for a listing/count tool that omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, offset, and site_ids are fully documented in the schema. The description reinforces site_ids ('details for specific site ids') and its detail difference, but adds no syntax beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (Mindbody sites/businesses), with the scope clarified as 'your developer account can access' and an alternate mode for 'specific site ids'. It is the only site-listing tool among the siblings, so disambiguation is trivial for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Offers one concrete use case – 'a cheap way to confirm the API key works' – which implies when to reach for it, but there is no explicit when-not-to-use, no prerequisites, and no named alternatives. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List staff members (instructors, practitioners). Filter by role, or find who is available for a session type at a location and time (session_type_id + location_id + start_date_time together). Without a staff token only public fields return. Mindbody: GET /staff/staff.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| filters | No | Filters to apply. | |
| staff_ids | No | Only these staff ids. | |
| location_id | No | Only staff available at this location (needs session_type_id and start_date_time). | |
| session_type_id | No | Only staff available for this session type (needs location_id and start_date_time). | |
| start_date_time | No | Only staff available at this time (needs session_type_id and location_id) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds a genuinely useful auth caveat – that without a staff token only public fields return. It does not discuss pagination behavior or result shape, but the token-scoping disclosure is real added value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the core purpose and the parameter-cluster constraint, closing with the underlying API route for traceability. No padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 7 optional parameters, no output schema and full schema coverage, the description covers purpose, usage modes, and the notable auth caveat. Only return-field/pagination detail is absent, and pagination is already documented in the schema, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each dependent parameter's description already states which siblings it needs, so the description's restatement of the session_type_id + location_id + start_date_time grouping is largely redundant. The vague 'filter by role' phrasing does not precisely map to the filters enum. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource and even disambiguates what 'staff' means ('instructors, practitioners'). It is clearly separable from siblings like mindbody_list_clients or mindbody_list_staff_appointments, though it never explicitly names a sibling to route the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete usage modes: plain filtering versus availability lookup, and explains the latter requires the three parameters together. It stops short of naming alternatives or stating when not to use this tool, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List booked appointments in a date range, by staff member, client or appointment id — the appointment book. Mindbody: GET /appointment/staffappointments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (request.limit), 1-200. Mindbody defaults to 100. | |
| offset | No | Page offset (request.offset). Mindbody defaults to 0. See PaginationResponse.TotalResults. | |
| end_date | No | End of the range (default start_date) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| client_id | No | Only this client's appointments. | |
| staff_ids | No | Only these staff ids (omit for all staff). | |
| start_date | No | Start of the range (default today) — ISO 8601, e.g. 2026-10-01 or 2026-10-01T09:00:00. | |
| location_ids | No | Only at these location ids. | |
| appointment_ids | No | Only these appointment ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds the appointment-book framing and the upstream endpoint mapping, but discloses no pagination behavior, default handling, or result format, so it contributes moderate value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence carrying the resource, scope and filters, followed by a compact endpoint reference. No filler sentences; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 fully-described parameters, readOnly annotations, and no output schema to explain, the description covers what an agent needs to invoke the tool. Minor gap: no mention of pagination behavior, though the schema's PaginationResponse.TotalResults note compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (limit, offset, dates, client_id, staff_ids, location_ids, appointment_ids) is already documented in the schema. The description only restates the filter axes without adding format or default semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (booked appointments) with the filtering axes (date range, staff, client, appointment id) and an anchoring phrase, 'the appointment book'. It does not explicitly name or distinguish itself from similar siblings like mindbody_get_class_visits or mindbody_list_client_visits, so a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the filter list (you'd use it to find appointments for a staff member, client, or id), but there is no explicit when-to-use vs alternatives guidance and no prerequisites or exclusions. Adequate but leaves routing to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reschedule or edit an appointment (start/end time, staff, session type, notes — the only fields Mindbody lets you change) and/or move it through its status: confirm, unconfirm, arrive, unarrive, complete. Cancel and late-cancel are deliberately not offered (a late cancel can charge the client). Pass test: true to validate only. Requires a staff user token. Mindbody: POST /appointment/updateappointment.
| Name | Required | Description | Default |
|---|---|---|---|
| test | No | When true, Mindbody validates the request but commits nothing. Use it to dry-run a write. | |
| notes | No | Replace the appointment notes. | |
| execute | No | A status action to apply. | |
| staff_id | No | Move to this staff member. | |
| send_email | No | Send the site's automatic email. | |
| end_date_time | No | New end, ISO 8601. | |
| appointment_id | Yes | The appointment id (from mindbody_list_staff_appointments). | |
| session_type_id | No | Change the session type. | |
| start_date_time | No | New start, ISO 8601. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description builds on that with real substance: a required staff user token, a validate-only mode, the fact that cancel is withheld because of a client charge, and a hard statement that only certain fields are mutable. This is the kind of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary action and reason for the cancel exclusion; the parenthetical enumerations are efficient. The trailing 'Mindbody: POST /appointment/updateappointment' line adds little for an agent choosing or invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, no-output-schema mutation tool this covers the essentials: what changes, what is forbidden, the required auth context, a dry-run escape hatch, and the underlying endpoint for error mapping. Nothing an agent needs to call it safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning by asserting that start/end time, staff, session type and notes are the only fields Mindbody permits changing, which constrains expectations for the full 9-parameter surface (send_email, execute, test are left to the schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource combination ('Reschedule or edit an appointment') and enumerates the two distinct mutation axes: field edits (time, staff, session type, notes) and status transitions (confirm/unconfirm/arrive/unarrive/complete). It is clearly separable from the add/list siblings at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames when to use it (reschedule/edit and/or status change) and when not to (cancel and late-cancel are deliberately excluded, with the reason: a late cancel can charge the client). Adds a dry-run path via test:true, which routes the agent away from unintended writes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on an existing client record — only the fields you pass change. No card or billing data is accepted. cross_regional_update (Mindbody default: true) also updates the client's profiles at the region's other sites. Pass test: true to validate only. Mindbody: POST /client/updateclient.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City. | |
| test | No | When true, Mindbody validates the request but commits nothing. Use it to dry-run a write. | |
| No | Email address. | ||
| state | No | State / region. | |
| gender | No | Gender, as configured at the site (see the site's genders). | |
| country | No | Country. | |
| client_id | Yes | The client's ID (RSSID — a string, as configured by the business; see mindbody_list_clients). | |
| last_name | No | Last name. | |
| birth_date | No | Date of birth, ISO 8601 (e.g. 1990-04-12). | |
| first_name | No | First name. | |
| home_phone | No | Home phone number. | |
| work_phone | No | Work phone number. | |
| is_prospect | No | Mark the client as a prospect (only if the site allows prospects). | |
| middle_name | No | Middle name. | |
| postal_code | No | Postal code. | |
| referred_by | No | How the client was referred (one of the site's referral types). | |
| mobile_phone | No | Mobile phone number. | |
| address_line_1 | No | Street address, line 1. | |
| address_line_2 | No | Street address, line 2. | |
| send_account_emails | No | Opt in/out of account notification emails. | |
| send_schedule_emails | No | Opt in/out of schedule notification emails. | |
| cross_regional_update | No | Propagate to the client's profiles at the region's other sites (Mindbody default: true). | |
| send_promotional_emails | No | Opt in/out of promotional emails. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint=true, so the description carries most of the load and does so well: it discloses that unset fields are left untouched, that cross_regional_update defaults to true and propagates writes to other sites, and that test=true commits nothing. It does not say whether fields can be cleared, nor what permissions/errors to expect, leaving a real gap for a destructive mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences, front-loaded with the mutation contract before defaults and the dry-run escape hatch. The trailing 'Mindbody: POST /client/updateclient' line is mildly useful for API mapping but is the one element that does not help an agent decide or call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 23-parameter destructive update with no output schema, the description covers the essentials: which fields mutate, the site-propagation default, and a safe validate-only path. It leaves open field-clearing behavior and failure/permission conditions, which is a modest but real omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 23 parameters, so the baseline is 3. The description's parameter-level claims (cross_regional_update default, test dry-run) largely restate what the schema descriptions already say, and 'no card or billing data is accepted' documents an absence rather than adding usable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Update fields on an existing client record') and immediately pins down the patch semantics with 'only the fields you pass change.' The phrase 'existing client record' implicitly separates it from the sibling mindbody_add_client, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational guidance: partial-update behavior, a dry-run via 'test: true', and the default-on cross-regional propagation. It never explicitly states when to prefer this over update-adjacent siblings or what prerequisites (permissions, client existence) must hold, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
mindbody_add_appointment1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_add_client1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_add_client_to_class1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_get_class_visits1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_get_client_account_balances1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_bookable_items1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_class_schedules1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_classes1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_client_memberships1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_client_visits1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_clients1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_locations1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_sales1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_services1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_session_types1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_sites1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_staff1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_list_staff_appointments1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_update_appointment1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_update_client1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"mindbody_add_appointmentmindbody_add_clientmindbody_add_client_to_classmindbody_get_class_visitsmindbody_get_client_account_balancesmindbody_list_bookable_itemsmindbody_list_class_schedulesmindbody_list_classesmindbody_list_client_membershipsmindbody_list_client_visitsmindbody_list_clientsmindbody_list_locationsmindbody_list_salesmindbody_list_servicesmindbody_list_session_typesmindbody_list_sitesmindbody_list_staffmindbody_list_staff_appointmentsmindbody_update_appointmentmindbody_update_clientLook up Momence members, class schedules, bookings and memberships, and handle front-desk actions.
Read Teachworks students, families, tutors, lessons, invoices and payments; book lessons.
Check classes, attendance, customers, memberships and invoices in TeamUp and register customers.
Read and write NexHealth appointments, patients, providers and locations.
Add one secure layer between your agents and this server.