Conditioning workouts from a coached library: suggest, vary or invent one for your kit and time.
Scored across 7 tools
The lookup tools (find_movements, list_archetypes, list_equipment) and report_workout are clearly distinct, but generate_workouts, suggest_workouts, and vary_workout all produce unsaved generated workout text from the same engine. The descriptions do draw the line (unlike-library vs. close-to-library vs. variation of one existing workout), so it is workable, but the generate/suggest boundary is subtle enough to invite misselection.
All seven tools use a clean verb_noun snake_case pattern (find_movements, list_archetypes, generate_workouts, vary_workout, report_workout). Different verbs (generate/suggest/vary) carry real semantic distinctions rather than inconsistency.
Seven tools is well scoped for a workout-generation server: three lookup tools, three generation modes, and one feedback channel. Each earns its place with no filler.
vary_workout operates on 'one library workout' but there is no tool to list or fetch library workouts, so an agent has no way to discover the input it needs. Lookup coverage for movements, archetypes, and equipment is good, and the stateless generation design is deliberate, but the missing library-inspection operation is a real dead end.
Movement slugs whose name holds query (e.g. "row", "sled"), for
suggest_workouts' include and exclude, machines and runs first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Keep one movement kind only, one of strength, olympic, plyo, cyclic, carry, mobility (cyclic: row, ski, bike, run); all when omitted. Example: "cyclic". | |
| query | Yes | Text the movement name holds, any case. Example: "sled". |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety needs no restating. The description does add a genuine behavioral trait beyond them — result ordering ('machines and runs first') — but the phrase is cryptic and no result limit or paging behavior is mentioned.
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 sentence with no filler, and the return type is front-loaded. The final clause 'machines and runs first' is grammatically clipped enough to cost a point on clarity, but 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 an output schema present there is no need to describe return shape, and the description names the downstream usage plus the matching and ordering semantics. Only the `kind` filter's effect on results is left undocumented outside the schema, a minor gap for a two-parameter read tool.
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% and both parameters carry examples, so the schema already does the heavy lifting. The description only reinforces that `query` is a substring match (illustrated by 'row' matching rows) and says nothing about the `kind` filter, which lives entirely in 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 the returned resource ('movement slugs') and the matching rule ('whose name holds `query`'), with concrete examples ('row', 'sled'). The verb is implicit and the trailing clause 'machines and runs first' is compressed, but an agent can still tell this is a name-substring lookup distinct from list_archetypes/list_equipment.
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 ties the tool to its downstream consumer: results feed suggest_workouts' include and exclude. That is clear usage context. It stops short of exclusions ('do not use to list all movements, use X instead'), which is why it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
New workouts unlike any in the library, from our generator (no AI), as text: evolved from the library's workouts and movements (more lines, fewer, other formats) into kinds it does not hold. For one person. Nothing is saved; other ones each call. suggest_workouts and vary_workout stay close to library workouts instead.
A shortfall says what blocked it.| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Who 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". | |
| count | No | How many workouts, at most 5. Example: 3. | |
| format | No | Only this format: for_time, amrap, emom, intervals. Any when omitted. Example: "amrap". | |
| exclude | No | Movement slugs or names (from find_movements) every workout must leave out. Example: ["burpees"]. | |
| include | No | Movement slugs or names (from find_movements) every workout must hold; fewer come back the more are named. Example: ["wallballs"]. | |
| equipment | No | What 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. | |
| bodyweight | No | False also leaves out movements needing no equipment (burpees, runs), so only the listed equipment is used. Example: false. | |
| minutes_max | No | Longest estimated workout length, in minutes. Example: 25. | |
| minutes_min | No | Shortest estimated workout length, in minutes. Example: 10. | |
| show_scores | No | True 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds meaningful behavioral context beyond that: nothing is saved, each call produces other ones, and a shortfall will say what blocked it. This is useful for a generation tool, though it does not cover all potential operational details such as rate limits.
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?
The description is short and front-loads the core purpose before giving sibling comparisons and failure behavior. However, the phrasing is somewhat awkward and run-on, with parentheticals and an unclear phrase like 'other ones each call,' which reduces clarity.
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?
Given the rich input schema, output schema, and annotations, the description covers the essential non-schema context: it generates novel non-AI workouts, saves nothing, and explains failure output. It is complete enough for an agent to call it correctly, though the unusual generator concept could benefit from a slightly clearer statement of return shape or intended use case.
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 the input schema already richly documents each parameter, including defaults, examples, and constraints. The description itself adds little direct parameter meaning beyond general framing like 'For one person' and 'as text'. With schema doing the heavy lifting, a baseline score of 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?
The description clearly states that this generates new workouts unlike any in the library, using a non-AI generator and returning text. It explicitly distinguishes itself from suggest_workouts and vary_workout, which stay close to existing library workouts. An agent can identify the tool's distinct purpose without opening the 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?
It names the alternatives suggest_workouts and vary_workout and explains the condition that selects them: they stay close to library workouts. It also indicates this tool is for new, library-unlike workouts and for one person. However, it does not spell out an explicit 'use this when' trigger or any prerequisites beyond the contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The workout archetypes the generator makes, one per line: key, name, formats, minutes, line count, and the session slots it serves.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Keep only one style's archetypes: crossfit, hyrox or hybrid; all when omitted. Example: "hyrox". |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds that results are a flat 'one per line' enumeration of a fixed field set, which is mild but real context about shape and stability; it says nothing about ordering, filtering behavior, or size.
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 sentence with no filler, front-loading the resource before the field breakdown. The phrasing 'the workout archetypes the generator makes' is slightly indirect where a verb like 'List' would be crisper, but 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?
An output schema exists, so return values need no explanation, and the one optional parameter is fully specified in the schema. The remaining gap is minimal: no statement of ordering, pagination, or how the list relates to generate_workouts.
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?
With schema coverage at 100%, the sole `style` parameter and its enum values (crossfit, hyrox, hybrid) are already fully documented in the schema. The description contributes no additional semantics about filtering, so the baseline 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?
Names the resource precisely (workout archetypes produced by the generator) and enumerates the fields each entry carries, so an agent knows exactly what it is reading. It implicitly separates itself from generate_workouts (which produces workouts) but never names any sibling 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?
Usage is only implied: an agent can infer this is the catalogue lookup to run before generating workouts, but the description never states when to call it, when not to, or which sibling to prefer. No prerequisites or follow-up guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The equipment suggest_workouts' equipment takes, one per line:
key: name, with "(machine)" on ergometers (rower, ski erg, bikes).
Keys, names and common names ("echo", "row erg", "DB", "kb") all work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the one-per-line 'key: name' output shape, the '(machine)' suffix convention on ergometers, and the fact that keys, names, and colloquial aliases ("echo", "DB", "kb") are all accepted inputs.
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?
Very short and front-loaded, with no filler. The opening clause ('The equipment suggest_workouts' `equipment` takes, one per line') is grammatically tangled and costs a moment of parsing, but the content density is high.
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 zero-parameter, read-only enumeration with an output schema and full annotation coverage, almost everything needed is present, including the cross-reference to the consumer of this data. Only minor gaps remain, such as whether the list is static or how ordering works.
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?
This tool takes zero parameters, so the baseline is 4; there is nothing for the description to compensate for. The alias note ("echo", "row erg", "DB", "kb") is a bonus that helps the agent map user phrasing to the returned keys.
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 identifies the resource (equipment) and, crucially, ties it to suggest_workouts' `equipment` parameter, which distinguishes it from siblings like list_archetypes or find_movements. The verb 'list' only comes from the name, not the prose, so it falls short of a clean verb+resource statement.
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 rather than stated: by framing the output as the accept: "The equipment suggest_workouts' `equipment` takes" it implies this tool is the discovery step before calling suggest_workouts. There is no explicit 'use this when...' or 'do not use for...' sentence, and no mention of the other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send Goblin Gains what the user thinks of a workout from these tools. Call it whenever the user points out a mistake (wrong equipment, a weight, a dose that cannot fit) or says a workout is bad or good: the words go to Goblin Gains, nothing else about the user does.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | What the user said about the workout, in their words. Example: "Farmers carry needs two dumbbells; I said I have one." | |
| verdict | Yes | One of mistake, bad, good: "mistake" (something in it is wrong), "bad" (it works but is a poor workout), "good". Example: "mistake". | |
| workout | No | The workout's save link from suggest_workouts, vary_workout or generate_workouts, or its id; omitted for the tools as a whole. Example: "https://app.goblingains.com/w/<id>". |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this is a non-read-only, non-idempotent, non-destructive write; the description adds real behavioral context by stating exactly what data leaves the client ('the words go to Goblin Gains, nothing else about the user does'), which is a privacy/data-minimization guarantee unavailable from annotations. It does not contradict readOnlyHint=false or idempotentHint=false.
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 short sentences, front-loaded with the action and followed by the trigger conditions and the privacy scope. The phrase 'from these tools' is slightly ambiguous, but there is no padding or repetition.
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 an output schema present and full parameter documentation, the description only needs to convey intent and data exposure, which it does. A note about whether repeat reports are allowed (non-idempotent) would close the 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 the schema already explains note, verdict, and the optional workout link in detail. The description reinforces the 'in their words' semantics of the note but adds no format or edge-case guidance beyond the schema, 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?
The description states a specific verb and resource: send the user's opinion of a workout back to Goblin Gains, scoped to workouts produced by 'these tools'. It is clearly the only feedback-reporting tool among the siblings, though the differentiation is implicit rather than stated.
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?
'Call it whenever the user points out a mistake (wrong equipment, a weight, a dose that cannot fit) or says a workout is bad or good' gives concrete triggers with example categories. There is no explicit when-not or named alternative, but none of the siblings overlap with this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Who 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". | |
| only | No | True: the workouts hold the included movements and nothing else (each may repeat). Needs include. Example: true. | |
| count | No | How many workouts, at most 5; from 3 on, a mix of archetypes (at most 2 of one unless nothing else fits). Example: 3. | |
| people | No | How 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. | |
| exclude | No | Movement slugs or names (from find_movements) every workout must leave out. Example: ["burpees"]. | |
| include | No | Movement slugs or names (from find_movements) every workout must hold. Example: ["wallballs", "sled-push"]. | |
| partner | No | True: 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. | |
| archetype | No | A key or name from list_archetypes; any when omitted. Example: "A5" or "chipper". | |
| equipment | No | What 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. | |
| bodyweight | No | False also leaves out movements needing no equipment (burpees, runs), so only the listed equipment is used. Example: false. | |
| cap_minutes | No | A time cap the workout must fit, in whole minutes. Example: 30. | |
| minutes_max | No | Longest estimated workout length, in minutes. Example: 60. | |
| minutes_min | No | Shortest estimated workout length, in minutes. Example: 40. | |
| show_scores | No | True 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. | |
| temperature | No | 0 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, non-idempotent), and the description adds real value on top: output is text, nothing is saved, and "a shortfall says what blocked it" warns that constraints may go unsatisfied and will be explained. It stops short of describing result volume or how partial results are shaped.
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?
Purpose and the non-persistence caveat are front-loaded, followed by a compact worked example and one line on shortfalls. Every sentence earns its place; the example is slightly long but directly instructive.
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 15 fully-documented parameters, an output schema, and complete annotations, the description covers the non-obvious behavioral facts (nothing saved, shortfalls reported). The only meaningful gap is failing to position it against generate_workouts and vary_workout.
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 is already fully documented, including equipment naming quirks and the bodyweight/equipment interaction. The description's example illustrates a realistic multi-parameter combination but adds no syntax or semantics beyond the schema, 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+resource ("New workouts from our generator, as text") and adds a key scoping fact: nothing is persisted. It does not, however, distinguish itself from the sibling generate_workouts or vary_workout, which an agent must disambiguate by schema alone.
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?
"Ask this instead of writing workouts yourself" gives a clear condition for reaching for this tool versus improvising. The worked example further anchors usage, but there is no explicit when-not guidance relative to the very similar sibling generate_workouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Variations of one library workout from our generator (no AI), as text, in its own format or another. Nothing is saved.
A shortfall says what blocked it.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Who 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". | |
| name | Yes | The library workout's name or part of it, any case; several matches are an error listing them (up to 10) to ask again. Example: "Fran". | |
| count | No | How many variations, at most 5. Example: 3. | |
| format | No | Turn it into this format first: for_time, amrap, emom, intervals. About its minutes: an EMOM gives each line its own minute when a round is over 40 s, intervals rest as long as a round's work. Omitted keeps its own. Example: "emom". | |
| people | No | How 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. | |
| equipment | No | What 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 the kit the workout already uses. | |
| bodyweight | No | False also leaves out movements needing no equipment (burpees, runs), so only the listed equipment is used. Example: false. | |
| show_scores | No | True 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. | |
| temperature | No | 0 to 1, how far they stray from it (0.2 close, 1 far). Example: 0.5. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description usefully reinforces this with 'Nothing is saved' while adding genuinely new traits: output is text, variations come from a deterministic non-AI generator, and failures surface as a shortfall message explaining what blocked it. Rate limits and the exact shape of the shortfall message are left unstated, but the behavioral picture is solid for a read-only tool.
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 short sentences, front-loaded with the core purpose and with zero filler. 'A shortfall says what blocked it' is slightly cryptic in isolation but still earns its place by flagging error behavior.
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 an output schema present and every one of the nine parameters documented, the description only needs to frame the operation, and it does: source workout, output as text, no persistence, partial-result reporting. The notion of a 'shortfall' (fewer variations than requested) could be spelled out, but nothing essential for 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% and the parameter descriptions are unusually rich (equipment keys, people/partner logic, format conversions, score meanings). The description adds almost nothing beyond them, aside from hinting that the format option is 'its own format or another', which the format parameter already explains. Baseline 3 applies 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?
The description states a concrete resource (variations of one existing library workout) and its output form (text, in the workout's own format or a converted one), plus the notable constraint that the generator is non-AI. It doesn't name sibling tools like generate_workouts or suggest_workouts, so differentiation is left to inference from 'library workout'.
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 explicit when-to-use statement and no named alternatives among the siblings (generate_workouts, suggest_workouts, find_movements). The only guidance is implicit: it operates on a workout already in the library, and 'nothing is saved' implies a preview-style call. An agent must guess why it would pick this over generating or suggesting workouts.
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.
find_movementsgenerate_workoutslist_archetypeslist_equipmentreport_workoutsuggest_workoutsvary_workoutBuild a workout that fits your time, gear and body — free, no sign-in.
Create and schedule interval workouts (Tabata, AMRAP, EMOM) from your real training history.
Coach-built training: coaching brains, programs, race plans, gyms, clinics, demos and your log.
CrossFit and HYROX workout search, benchmark targets, scaling guidance, and movement technique.
Add one secure layer between your agents and this server.