Phorme Training

Book a Phorme gym class

book_gym_class

Idempotent

Use this when a signed-in user wants a place in one class at a Phorme gym or studio. Confirm the class, the day and time, and the gym with the user first, and set confirmation to true only after they said yes. It books the class for the connected Phorme account: booked when there is a spot, on the waitlist when it is full, a spot held for 15 minutes when the class is paid, or a request the gym is told about when the gym has not opened booking on Phorme yet. A paid class is finished from the gym's page on phor.me. This tool takes no payment, gives no payment link, names no amount and never sells a subscription or membership. Booking the same class again returns the same booking. It needs a connected Phorme account with the training:write permission.

Input Schema

Name	Required	Description
`class_id`	Yes	The class_id of the class, from find_gym_class.
`place_id`	No	The place_id of its gym or studio, from the same find_gym_class result.
`confirmation`	Yes	Set to true only after the user said yes to this class, day, time and gym.

Output Schema

Name	Required	Description
`next`	Yes	What to tell the user next.
`class`	No	title, starts (local time at the gym) and minutes.
`place`	No	name, city and page_url of the gym or studio.
`status`	Yes	booked: the user is in. waitlisted: the class is full; Phorme moves them up if a spot opens. pending_payment: the class is paid and the spot is held 15 minutes; they finish booking it from place.page_url. requested: the gym is told they asked; held up to 7 days, not a booking yet. book_on_phorme: nothing was booked; give them book_url.
`book_url`	Yes	The class page on phor.me.
`booking_id`	Yes	The booking, for cancel_gym_booking.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 25, 2026

removedOutput schema / properties / pay_url

Removed value: -{
-  "description": "Phorme's own payment page for this booking, only when status is pending_payment.",
-  "type": [
-    "string",
-    "null"
-  ]
-}

changedOutput schema / properties / status / description

Previous value: -"booked: the user is in. waitlisted: the class is full; Phorme moves them up if a spot opens. pending_payment: the spot is held 15 minutes while they pay at pay_url. requested: the gym is told they asked; held up to 7 days, not a booking yet. book_on_phorme: nothing was booked; give them book_url."New value: +"booked: the user is in. waitlisted: the class is full; Phorme moves them up if a spot opens. pending_payment: the class is paid and the spot is held 15 minutes; they finish booking it from place.page_url. requested: the gym is told they asked; held up to 7 days, not a booking yet. book_on_phorme: nothing was booked; give them book_url."

AddedOct 19, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond annotations: enumerates all four outcome states (booked, waitlist, 15-minute hold for paid classes, request forwarded when booking isn't open), states the permission prerequisite (training:write), and clarifies that no payment, payment link, amount, or subscription is involved. It also discloses idempotent behavior with the concrete consequence ('same class again returns the same booking'), complementing the idempotentHint annotation.

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 trigger and the confirmation requirement, then the outcome model, then guardrails. The payment clause is somewhat repetitive ('takes no payment, gives no payment link, names no amount') but each variant guards a distinct failure mode, so the length is largely earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety/idempotency and an output schema covering return values, the description still supplies the things structured fields can't: the outcome branching, the auth requirement, the confirmation protocol, and the explicit payment boundary. Nothing an agent needs to invoke it correctly is missing.

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 class_id, place_id, and confirmation are already fully documented, including the const:true constraint and the find_gym_class provenance. The description reinforces the confirmation semantics but adds no syntax or format detail 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource + scope: 'book a place in one class at a Phorme gym or studio' for the connected account. An agent can distinguish it from find_gym_class (discovery) and cancel_gym_booking (reversal) without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger ('when a signed-in user wants a place in one class') plus a mandatory pre-step ('confirm the class, the day and time, and the gym with the user first, and set confirmation to true only after they said yes'). It does not name find_gym_class as the required discovery alternative, but the dependency is stated in the schema rather than the description.

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

All Phorme Training 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.