add_client_to_classBook a client into a class session (or its waitlist). Uses the client's first available membership/credit unless payment_option_id is given. [requires scope: book]
| Name | Required | Description | Default |
|---|---|---|---|
| spot_id | No | Reformer/spot id (optional) | |
| waitlist | No | ||
| client_id | Yes | ||
| class_session_id | Yes | ||
| payment_option_id | No | From get_payment_options (optional) | |
| payment_option_type | No | membership | credit (required with payment_option_id) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, destructive operation, and the description adds meaningful behavioral detail: it automatically consumes the client's first available membership/credit unless overridden by payment_option_id, and it requires the 'book' scope. This explains the main side effects beyond the structured annotations.
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-load the main action, then provide the payment side effect and the required scope. There is no filler or repetition of schema details.
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 booking action with six parameters and no output schema, the description covers the key side effect and auth requirement but omits error/waitlist edge behavior and does not disambiguate from sibling booking tools. It is adequate but not fully 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?
The description adds semantic value to payment_option_id by explaining it overrides the default first-available membership/credit selection. It also frames the waitlist flag with 'or its waitlist'. Schema coverage is only partial, so this extra explanation is useful, though spot_id's role is 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?
The description states a specific action ('Book a client into a class session') and identifies the waitlist option, making the core purpose immediately clear. It does not explicitly distinguish this from siblings such as move_client_to_class or promote_from_waitlist, so it falls just short of full differentiation.
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 description implies usage: book a client into a class or its waitlist, and it provides a conditional payment behavior ('unless payment_option_id is given') plus a required scope. However, it does not explicitly say when to use this instead of move_client_to_class, promote_from_waitlist, or remove_client_from_class.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, and the descriptions carefully separate operations like attendance_report, list_classes, and get_class_roster. A few reads overlap conceptually (get_client, get_reservation_history, get_credit_history, get_client_notes all return client-related data), but each has a specific output that an agent can distinguish with reasonable effort.
Tool names overwhelmingly follow a consistent action_object pattern: add_client_note, cancel_class, freeze_membership, refund_order, set_client_tag, unfreeze_membership. The get_/list_ prefix distinction is used predictably, and auth tools (login, logout, whoami) are standard exceptions rather than inconsistent naming.
41 tools is well beyond the 25+ threshold for a heavy tool set. Although each tool appears to serve a real studio-operations need, the sheer number creates a large surface for an agent to navigate and places significant burden on selection accuracy.
The tool set covers the core lifecycle well across clients, classes, memberships, orders, payments, and communications, with no obvious dead ends. Minor gaps exist, such as no update_client profile tool and no class-scheduling creation, but staff workflows can generally be completed.