Build a workout that fits your time, gear and body — free, no sign-in.
Scored across 5 tools
Each tool targets a distinct resource+action: build creates, search finds, get fetches a specific workout, list_contributors enumerates people, get_contributor fetches one person. The potentially confusable pair (build_workout vs search_workouts) is explicitly separated in descriptions, with search even redirecting to build when nothing fits.
All five tools follow a clean verb_noun snake_case pattern: build_workout, get_workout, search_workouts, list_contributors, get_contributor. The get_/list_/search_/build_ verbs map predictably to fetch-one, enumerate, filter, and create semantics.
Five tools is tightly scoped for a workout discovery-and-generation server; each tool covers a distinct need (create, browse, retrieve, contributor lookup) with no redundancy. Nothing feels padded or missing at the count level.
The read-and-generate lifecycle is well covered: search/browse workouts, fetch details, and build custom sessions, plus contributor browsing. Minor gaps exist — no way to save, update, or list a user's own workouts or profile/goal persistence — but core agent workflows are fully served.
What workout can I do with this time, this gear, and this body? GetFit's coach builds a complete session that fits the minutes, uses only the equipment they have, and steers around anything they want to avoid. Give the person the whole workout in the chat — warm-up, every exercise with sets, reps, rest and effort — and read out the safety_notes. The workout is also posted to GetFit's public Explore page (no personal details), and link opens it in GetFit, where the Player runs it with timers and rest countdowns. Inputs (all optional): focus, minutes, equipment, avoid, level, goal, intensity. Example: {"focus":"legs","minutes":30,"equipment":"from home","avoid":["knees"]}.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | e.g. "strength", "fat loss", "endurance" | |
| avoid | No | Body parts or movements to avoid: "knees", "lower back", "jumping". | |
| focus | No | What to train, in plain words: "legs", "upper body", "full body", "core". | |
| level | No | ||
| minutes | No | Time available, warm-up included (5-120). Treated as a hard ceiling. Default 30. | |
| equipment | No | What they have: a preset (none | dumbbells | hotel_gym | full_gym), free text ("a couple of dumbbells", "from home"), or a list. Nothing named → bodyweight. | |
| intensity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses that the workout is published to a public Explore page (no personal details), that `link` opens it in GetFit's Player with timers, and that the agent should read out safety_notes. These are meaningful side-effect and output-handling details an agent needs and annotations alone (readOnlyHint=false, openWorldHint=true) don't convey.
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?
Front-loaded with the core question and purpose, then output guidance, then inputs and an example. Slightly dense sentence about the Explore page and Player, but every sentence carries information. No filler.
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 no output schema, the description fully compensates by describing the return contents (warm-up, exercises with sets/reps/rest/effort, safety_notes, link) and the public-posting behavior. An agent has everything needed to call it and present results correctly.
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 coverage is 71% and the description reinforces that all inputs are optional and lists them, plus supplies a concrete example call ({"focus":"legs","minutes":30,"equipment":"from home","avoid":["knees"]}) that clarifies accepted value shapes. That example adds real value beyond the schema, though it doesn't deepen semantics of enums like intensity.
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?
Specific verb+resource: builds a complete session matching time, gear, and avoidances. The framing question plus 'builds a complete session' makes clear it's a generative tool, distinguishable from retrieval siblings like get_workout and search_workouts. It doesn't explicitly name those siblings, which keeps it just below 5.
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?
Clear context for when to invoke: when a person wants a workout fitted to minutes, equipment, and constraints. The example anchors typical use. However, it doesn't state when NOT to use it or explicitly route to search_workouts/get_workout as alternatives, so it falls short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who is this GetFit contributor and what have they posted? Input: handle from list_contributors. Example: {"handle":"jenna"}.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds the useful fact that the response includes the contributor's posts, which is not in any structured field; error behavior for invalid handles is the only notable omission.
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 compact sentences plus an example, front-loaded with the core question. The example is useful rather than filler; the phrasing is slightly informal but not wasteful.
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 single-parameter read with full annotation coverage and no output schema, this covers purpose, input source, and partial return content. It could say more about the shape of the returned contributor record, but nothing essential 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 coverage is 0% (the handle field has no description), so the description must compensate, and it does: it identifies where the handle value comes from and gives a concrete JSON example of the expected format.
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 a specific resource (GetFit contributor) and what it returns (profile plus their posts), so the agent knows this is a detail lookup rather than a listing. It is distinguishable from list_contributors, though it doesn't explicitly contrast with 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?
Explicitly states the prerequisite: the handle must come from list_contributors. That routes the agent correctly, but no guidance on when to prefer this over search_workouts or what to do for an unknown handle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show me that workout in full. Returns author, discipline, duration, warm-up, coach note and every exercise (sets, reps, rest, cues). Input: slug from search_workouts. Example: {"slug":"the-45-minute-pull-day"}.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds genuine behavioral value by disclosing the shape of the returned payload (nested exercises with sets, reps, rest, cues), which matters because there is no output schema. It does not mention behavior on an unknown slug.
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?
Front-loaded with the essential scope, then return contents, then input source, then example — a sensible order with no filler. The conversational opener 'Show me that workout in full' is slightly informal but does double duty as a scope statement.
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 one param, no output schema, and full annotation coverage, the description supplies exactly the missing pieces: what is returned and how to obtain the slug. Only a note on missing/invalid slug behavior is absent.
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 coverage is 0% — the single 'slug' parameter is bare in the schema. The description compensates well by stating the slug's provenance ('from search_workouts') and giving a concrete example value, making the expected format unambiguous.
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 ('Show me that workout in full') and immediately enumerates what 'full' means: author, discipline, duration, warm-up, coach note, every exercise. This distinguishes it from the sibling search_workouts (which returns matches, not full detail) without naming that 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?
The phrase 'Input: slug from search_workouts' establishes the workflow: search first, then fetch full detail by slug. It does not state when NOT to use it (e.g., to browse multiple workouts, use search_workouts/list), but the implied sequencing is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who posts workouts on GetFit? Lists people with published workouts: handle, name, bio, location, workout count. No inputs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description still adds real value by disclosing the returned attributes (handle, name, bio, location, workout count), which is the main unknown for an agent with no output schema; only pagination/ordering behavior is undisclosed.
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, purpose front-loaded and zero filler. The opening rhetorical question is slightly indirect compared to a direct verb-first statement, but it costs almost nothing.
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 list with full annotation coverage, the description covers what the tool is, that it takes nothing, and roughly what comes back. It stops short of noting ordering or whether the result set is bounded/paginated, the one 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?
There are zero parameters and the description correctly says so ('No inputs'), matching the empty schema. Baseline 4 applies for a no-parameter tool with nothing left to disambiguate.
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 — lists people with published workouts — and enumerates the fields returned (handle, name, bio, location, workout count). The plural 'lists' plus the field set clearly distinguishes it from the single-record sibling get_contributor and from the workout-oriented siblings.
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 browse-all path versus get_contributor for one person, but the description never names that alternative or any exclusion. 'No inputs' does helpfully signal a bare call needs no setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What workouts are on GetFit for legs / 20 minutes / dumbbells? Searches published workouts on Explore by body area, name, exercise and gear. If nothing fits, say so and offer build_workout to make one. Inputs: query, focus, max_minutes, equipment, discipline, source (people | agent | any), limit (default 5, max 20). Example: {"query":"legs","max_minutes":30,"equipment":"dumbbells"}.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Body area, e.g. "legs", "upper body" | |
| limit | No | ||
| query | No | Plain words: "legs", "pull day", "core" | |
| source | No | people = posted by GetFit members and trainers; agent = built on request | |
| equipment | No | What they have (preset, free text or list); results stay within it. | |
| discipline | No | ||
| max_minutes | No |
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 behavior the annotations don't: results are limited to published content on Explore, equipment filters act as a hard constraint ('results stay within it'), and limit defaults to 5 with a max of 20.
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?
It is front-loaded with the user-facing question, then behavior, then fallback, then a compact input roll-call and a concrete example. The 'Inputs:' list partly restates the schema, but it is short and the example earns its 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 7-parameter read tool with no output schema, it covers the searchable dimensions, the source modes, the result cap, and the fallback path. It doesn't sketch the shape or ordering of returned results, and the focus/query relationship is left ambiguous, which are the remaining gaps.
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 coverage is 57%, and the description fills some gaps — the limit default and cap, the source enum meaning, and an example showing how query/max_minutes/equipment combine. But focus versus query overlap is never disambiguated and discipline, max_minutes, and equipment formats get only partial treatment, so it doesn't fully compensate for the coverage gap.
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 — searches published workouts on Explore — and scopes them by body area, name, exercise and gear. It is clearly distinguishable from the sibling build_workout, which it names as the creation alternative rather than the search path.
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 gives an explicit fallback rule: if nothing fits, say so and offer build_workout to make one. That is real routing guidance. It doesn't explain when to prefer get_workout (for a single known workout) or how it differs from that sibling, so it stops short of full alternative coverage.
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.
build_workoutget_contributorget_workoutlist_contributorssearch_workoutsCreate and schedule interval workouts (Tabata, AMRAP, EMOM) from your real training history.
Your AI writes training plans that arrive as structured workouts on iPhone and Apple Watch.
Read-only bodyweight workout builder and exercise form cues from the Upfit iPhone app.
Log workouts and meals by telling your AI. 873 exercises, muscle diagrams, food lookup.
Add one secure layer between your agents and this server.
