Skip to main content
Glama

Suggest workouts

suggest_workouts
Read-only

New workouts from our generator, as text. Ask this instead of writing workouts yourself. Nothing is saved.

Example, two people with an echo bike, rower and ski erg, 40-60 min:
suggest_workouts(count=5, people=2, minutes_min=40, minutes_max=60,
equipment=["echo-bike", "row-ergometer", "ski-erg"], bodyweight=False)

A shortfall says what blocked it.

Input Schema

NameRequiredDescriptionDefault
sexNoWho trains, for the weights and machine doses: "men", "women", or "mixed" (a man and a woman together: each at their own; Hyrox stations at the mixed doubles race load). Omitted when the user did not say: every line reads both, men's/women's ("9/6 kg", "12/10 kcal"). Anything but men gets only workouts with a women's weight on every loaded line. Example: "women".
onlyNoTrue: the workouts hold the included movements and nothing else (each may repeat). Needs include. Example: true.
countNoHow many workouts, at most 5; from 3 on, a mix of archetypes (at most 2 of one unless nothing else fits). Example: 3.
peopleNoHow many train together with one of each machine. Above 1, only workouts they can share come back: partner workouts (taking turns on a station), or EMOMs/intervals with a different machine on every line and at least one line per person (start apart, rotate). Example: 2.
excludeNoMovement slugs or names (from find_movements) every workout must leave out. Example: ["burpees"].
includeNoMovement slugs or names (from find_movements) every workout must hold. Example: ["wallballs", "sled-push"].
partnerNoTrue: only partner workouts (two people share the work: turns at a station, or each on a station at once, then swap). False: none. Omitted: either. Example: true.
archetypeNoA key or name from list_archetypes; any when omitted. Example: "A5" or "chipper".
equipmentNoWhat the athletes have, as list_equipment keys or names ("echo-bike" or "echo", "row erg", "ski erg"), one item per entry. Say "1 dumbbell" or "1 kettlebell" when there is only one: movements needing a pair (farmers carry, dumbbell bench press) are left out. Other counts are ignored ("1 echo" is the echo bike): say how many train in people. Movements needing anything else (a bench press needs a bench) are left out; runs need "running" in the list. A name matching several keys or none is an error naming them. Example: ["1 dumbbell", "box", "ski-erg"]. Omitted is a full gym.
bodyweightNoFalse also leaves out movements needing no equipment (burpees, runs), so only the listed equipment is used. Example: false.
cap_minutesNoA time cap the workout must fit, in whole minutes. Example: 30.
minutes_maxNoLongest estimated workout length, in minutes. Example: 60.
minutes_minNoShortest estimated workout length, in minutes. Example: 40.
show_scoresNoTrue adds a line of scores under each workout: feasibility (0-100, can it be done as written), difficulty (0-100, the chance of not finishing inside the cap), and against the workout it was made from: stimulus (0-1, CrossFit's stimulus kept, with the levers changed), work (x the seed's), mix shift (how far the work moved between movement patterns), design (0-1) and, for Hyrox workouts, race fidelity (0-1). Example: false.
temperatureNo0 to 1. 0: the same ask always brings the same workouts. Above 0: other ones each call, the higher the further from the library workouts they vary (0.3 close variations, 1 far ones). Example: 0.3.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint=false; the description reinforces this with "Nothing is saved" and adds a non-obvious failure behavior ("A shortfall says what blocked it"). It doesn't discuss latency, output shape, or determinism beyond what temperature's schema text already covers.

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?

Three short units with zero waste, and the purpose is front-loaded ahead of the example. The closing line "A shortfall says what blocked it" is terse to the point of being cryptic out of context.

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

Completeness4/5

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

For a 15-parameter generator with an output schema and full annotation coverage, the description gives enough to act: purpose, a concrete call, and the failure mode. It could say more about how results relate to generate_workouts or vary_workout, but the heavy documentation load is carried by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns a bump by demonstrating cross-parameter interaction in a single worked example (count, people, minutes_min/max, equipment, bodyweight together). The shortfall note also implies that conflicting filters are surfaced rather than silently ignored.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

"New workouts from our generator, as text" states a specific verb (generate) and resource (workouts) plus the output form and the non-persistent nature of the call. It does not distinguish itself from the sibling generate_workouts, which is a near-name collision an agent must resolve elsewhere.

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?

"Ask this instead of writing workouts yourself" gives a clear alternative and the condition that selects this tool. It stops short of naming sibling tools (generate_workouts, vary_workout) or stating when NOT to call it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources