Skip to main content
Glama

Add or update an exercise

upsert_exercise
DestructiveIdempotent

Create or update an exercise in the user's catalog (keyed by its id/name). An exercise from search_exercise_pool saved with its slug as the id plus pool_slug keeps one identity and one history, and inherits the pool's muscles, equipment and technique cues. A hand-written exercise shows in the muscle map and the app only when instructions (2-3 short technique cues, in the user's language), primary_muscles, category and equipment are set. Fields omitted are left as they are, so a partial update is safe.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
exerciseYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / exercise / properties / category / description
      Previous value: -"What kind of work this is. `cardio` and `mobility` deposit no muscle load at all, so never use them for resistance work — a stretch or a run tagged `compound` lights up the muscle map for days."New value: +"What kind of work this is. `cardio` and `mobility` deposit no muscle load, so they do not describe resistance work; a stretch or a run tagged `compound` shows on the muscle map for days."
    • changedInput schema / properties / exercise / properties / dose_unit / description
      Previous value: -"What this exercise is dosed in: 'reps' (the usual case), 'seconds' for holds and carries (plank, dead hang, farmer's walk), or 'minutes' for cardio. It says what the rep range and every logged set's number mean — a 60-second plank is not 60 reps."New value: +"What this exercise is dosed in: 'reps' (the usual case), 'seconds' for holds and carries (plank, dead hang, farmer's walk), or 'minutes' for cardio. It is the unit of the planned target; a logged set keeps reps in `reps` and time in `duration_sec` whatever it is, so a 60-second plank is never 60 reps."
    • changedInput schema / properties / exercise / properties / long_length / description
      Previous value: -"True when the target muscle is loaded in a stretched position (RDL, incline curl, Nordic curl); false when the stretched half is removed (rack pull, hip thrust, cable kickback). Its residual load persists longer in the muscle load model. Leave null only when you genuinely cannot tell from the movement."New value: +"True when the target muscle is loaded in a stretched position (RDL, incline curl, Nordic curl); false when the stretched half is removed (rack pull, hip thrust, cable kickback). Its residual load persists longer in the muscle load model. Null means unclassified, and the model then infers it from the movement pattern."
    • changedInput schema / properties / exercise / properties / movement_pattern / description
      Previous value: -"The pattern the movement belongs to (squat, hinge, horizontal_push, …). Keep it the same across variations of one lift: it is how the model judges whether a muscle is already accustomed to that pattern."New value: +"The pattern the movement belongs to (squat, hinge, horizontal_push, …). Variations of one lift share a pattern: the load model judges from it whether a muscle is already accustomed to that pattern, and injury checks match on it."
    • changedInput schema / properties / exercise / properties / pool_slug / description
      Previous value: -"The `slug` of the matching entry from search_exercise_pool, when this exercise comes from the curated pool. Set it whenever a pool entry matches — it keeps one movement under one identity even if the display name is later edited or translated."New value: +"The `slug` of the matching entry from search_exercise_pool, for an exercise that matches a curated pool entry. It keeps one movement under one identity even if the display name is later edited or translated."
    • changedInput schema / properties / exercise / properties / primary_muscles / description
      Previous value: -"The muscles the exercise is done FOR — the prime movers. These alone are counted against the weekly MEV/MAV set landmarks, so list the target, not everything the movement involves."New value: +"The muscles the exercise is done FOR, the prime movers; assisting and stabilising muscles are the secondary and tertiary lists. Only these count against the weekly MEV/MAV set landmarks."
    • changedInput schema / properties / exercise / properties / secondary_muscles / description
      Previous value: -"Muscles that assist meaningfully but are not the target (triceps on a bench press). They count in the muscle load model at a reduced weight. Never repeat a primary muscle here."New value: +"Muscles that assist meaningfully but are not the target (triceps on a bench press). They count in the muscle load model at a reduced weight. The list excludes the primary muscles."
    • changedInput schema / properties / exercise / properties / tertiary_muscles / description
      Previous value: -"Stabilisers and minor assistance (abs on a standing press). They count at a further reduced weight. Never repeat a muscle already listed as primary or secondary; leave empty when unsure."New value: +"Stabilisers and minor assistance (abs on a standing press). They count at a further reduced weight. The list excludes primary and secondary muscles; empty means unspecified."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: 'Fields omitted are left as they are, so a partial update is safe' and the identity/history inheritance from pool_slug.

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?

Four dense but purposeful sentences, front-loaded with the core create-or-update semantics before the pool/identity nuance and the partial-update guarantee. No filler, though the middle sentence is quite long.

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 nested-object upsert with an output schema (so return values need not be described) and strong annotations, the description covers identity, visibility requirements and partial-update semantics. It is complete enough for correct invocation, with only minor gaps around the remaining optional fields.

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?

Top-level schema description coverage is nominally 0% for the single `exercise` object, so the description must compensate — and it does, explaining id/name keying, the slug+pool_slug pairing, and which fields make a hand-written exercise visible. It adds meaning beyond the nested schema descriptions without fully enumerating every field.

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

Purpose5/5

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

States a specific verb+resource: 'Create or update an exercise in the user's catalog (keyed by its id/name).' It also distinguishes itself from the sibling search_exercise_pool by describing the pool-slug identity workflow, so an agent can tell this upsert apart from the read/import tools.

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?

It clearly explains the two usage paths: saving a pool entry (slug as id plus pool_slug) versus writing a hand-written exercise, and it names the fields required for the latter to appear in the muscle map/app. It stops short of an explicit 'call search_exercise_pool first when…' routing statement, but the context is unambiguous.

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.