CrossFit and HYROX workout search, benchmark targets, scaling guidance, and movement technique.
Scored across 3 tools
The tools mostly target distinct resources: workout detail, workout search, and movement lookup. There is some potential overlap because both search_movements and search_workouts can involve movement names, but the descriptions clarify that one returns movement details while the other searches workout summaries.
All names use a consistent snake_case verb_noun pattern: get_workout, search_movements, and search_workouts. The singular/plural distinction is also predictable, with get_workout returning one workout and search_* tools operating on collections.
Three tools are well-scoped for a read-only public workout and movement catalog. Each tool has a clear role, and the set avoids unnecessary surface area while covering lookup and discovery.
The surface covers workout detail, workout search, and movement lookup, which are the core read-only operations for this catalog. Minor gaps remain, such as browsing/listing all workouts or movements and fuzzy movement discovery when the exact canonical name or alias is unknown.
Get a public workout by its exact name or PRzilla slug, including its prescription, scaling notes, movements, and L2–L10 benchmark thresholds for available men's, women's, and vest variants. No personal scores are available.
| Name | Required | Description | Default |
|---|---|---|---|
| workout | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| levels | Yes | |
| scaling | No | |
| category | Yes | |
| movements | Yes | |
| score_type | Yes | |
| description | Yes | |
| time_cap_minutes | No | |
| intended_stimulus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive lookup. The description adds useful context beyond that: only public workouts are returned, personal scores are excluded, and the response includes specific prescription and benchmark data. It stops short of describing not-found or ambiguity behavior.
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 sentences, front-loaded with the core action and scope. The second sentence is short and adds a relevant exclusion; there is no wasted text.
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 lookup with an output schema, the definition supplies the key calling context: exact-name/slug input, public-only scope, and no personal scores. Minor gaps like not-found behavior are acceptable given the output schema and annotations.
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 0%, so the description must carry the burden. It does so by explaining that the single 'workout' parameter accepts an exact workout name or PRzilla slug, which is meaningful beyond the bare string schema. It does not cover case sensitivity, formatting, or ambiguity resolution.
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 a public workout by its exact name or PRzilla slug.' It also scopes the result content (prescription, scaling notes, movements, benchmark thresholds) and distinguishes exact lookup from searching by emphasizing the exact identifier.
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 'by its exact name or PRzilla slug' clearly indicates when this tool is appropriate versus a search tool, and 'No personal scores are available' sets a scope boundary. However, it does not explicitly name search_workouts as the alternative when the exact identifier is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one canonical movement name or alias, such as HSPU or thruster. Returns equipment, technique description, easier versions, progressions, a demo video when available, and example PRzilla workouts. These are catalog suggestions, not personalized prescriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| movement | Yes |
| Name | Required | Description |
|---|---|---|
| matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent, closed-world read operation. The description adds useful behavioral context by listing the kind of catalog information returned and clarifying that suggestions are not personalized prescriptions.
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 front-loaded with the lookup action and examples, then quickly lists expected output and scope caveats. Every sentence adds useful information without wasting space.
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 simple one-parameter lookup with an output schema and rich annotations, the description is complete enough. It defines the input domain, describes the catalog-style output, and sets expectations that results are suggestions rather than personalized prescriptions.
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 0%, so the description must carry the parameter meaning. It does this well by defining the sole input as one canonical movement name or alias and giving concrete examples, though it does not clarify matching behavior such as case sensitivity or partial matching.
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-resource pair: looking up one canonical movement name or alias, with examples like HSPU and thruster. The scope is clear, but it does not explicitly distinguish this from sibling tools such as get_workout or search_workouts.
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 'Look up one canonical movement name or alias' and the caveat that results are catalog suggestions, not personalized prescriptions. However, there is no explicit guidance on when to use this tool instead of search_workouts or get_workout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public PRzilla workout catalog by workout name or movement. Optionally filter by category. Returns workout links and short summaries; use get_workout for prescriptions and benchmark targets. Does not search an athlete's workout history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful context beyond that: it returns links plus short summaries (not full prescriptions) and is scoped to the public catalog only. It stops short of describing result ordering or pagination behavior, which is minor given limit is capped.
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 the routing hint, then the exclusion. No filler, each 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?
With an output schema present, the return shape needn't be spelled out, and the description still gives a useful preview ('workout links and short summaries'). The only real gap for a 3-parameter search tool is the unaddressed 'limit' semantics and result ordering.
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 0%, so the description has to compensate and only partly does: it clarifies that 'query' matches workout name or movement and that 'category' is an optional filter. The 'limit' parameter (default 5, max 10) is never mentioned, leaving one of three parameters entirely undocumented outside 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 ('Search the public PRzilla workout catalog'), the match fields (name or movement), and the scope boundary (not athlete history). An agent can distinguish this from get_workout and search_movements 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes downstream needs to get_workout for 'prescriptions and benchmark targets' and excludes athlete history searches. It does not name search_movements as the alternative for movement-only lookups, so the when-not coverage against all siblings is incomplete.
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.
get_workoutsearch_movementssearch_workoutsPublic fitness and nutrition calculators, exercise information, and evidence-based guides.
HYROX race calendar, race-weekend city guides, training guides and athletes to sponsor.
Read-only bodyweight workout builder and exercise form cues from the Upfit iPhone app.
Search exercises, read your training plans and schedule, and create plans in your Kubikos account.
Add one secure layer between your agents and this server.