list_swap_optionsValid alternatives for an exercise — same muscle group, filtered to the athlete's equipment/level/injuries. Use before swap_exercise.
| Name | Required | Description | Default |
|---|---|---|---|
| exerciseId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the filtering logic (same muscle group, equipment/level/injuries), which is valuable. However, it does not mention the return format, empty-result behavior, or invalid exerciseId handling, leaving some transparency gaps.
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 short sentences: the first conveys the core purpose, the second gives usage guidance. No redundant words, and the most important information is front-loaded.
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 tool with one parameter and no output schema, the description provides sufficient context about what it does and when to use it. 'Valid alternatives' implies the return type. Minor gaps like exact return structure don't impede correct invocation.
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 schema has only exerciseId with no description, so the description must clarify its meaning. The phrase 'for an exercise' implicitly defines exerciseId as the target exercise. This adequately compensates for the 0% schema coverage given the single-parameter simplicity.
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 the tool lists valid alternatives for an exercise, specifying same muscle group and filters by equipment/level/injuries. This distinguishes it from the sibling swap_exercise, which performs the swap. The title reinforces the purpose.
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 states 'Use before swap_exercise,' telling the agent exactly when to call this tool relative to its sibling. This is a clear workflow directive. The description also implies this is a prerequisite, which is sufficient guidance.
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.
Each tool targets a distinct action or resource: program retrieval, session guidance, workout logging, readiness check-in, exercise swaps, nutrition targets, and meal planning. Even the closely related list_swap_options and swap_exercise have clear separation (viewing alternatives vs. applying a change). No two tools could be reasonably confused.
Tool names are predominantly snake_case with a verb_noun pattern (get_program, list_swap_options, log_workout, regenerate_program, swap_exercise). However, a few are plain nouns (changelog, meal_plan, nutrition_targets) and readiness_checkin is a noun phrase, breaking the strict verb-first convention. This is a minor deviation that does not hinder readability.
With 10 tools, the server is well-scoped for a fitness coaching domain. Every tool addresses an essential aspect of the coaching loop: program viewing, daily session delivery, workout logging, readiness tracking, nutrition guidance, exercise modification, and explanation of changes. The count is within the ideal range and none feel redundant.
The tool surface covers the core lifecycle: get program, regenerate program, view today's session, log workout, check in readiness, swap exercises, and access nutrition targets and meal plans. Notable gaps include no explicit workout history/retrospective tool and no direct profile management, but these are likely handled externally or can be worked around. The inclusion of a changelog nicely closes the feedback loop.