Skip to main content
Glama
RedFoxxo

leap

by RedFoxxo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

write_log_workout

Destructive

Log a finished workout to leap by recording exercises, sets, weights, reps, cardio, timed holds, and per-side details so volume and PRs update.

Instructions

Log a finished workout. Sets: weight + reps (done defaults to true), warmup, rir and/or rpe, failure (taken to failure), a drop set (drops), rest-pause (clusters; reps is the total), a pyramid's Max set (max), per side (left and right, each with its own weight, reps, rir/rpe and drops or clusters), timed (sec, optional weight; a hold per side is two rows, side L then R) or cardio (min, speed in km/h, optional incline in % with min). Weights in the profile unit; for a dumbbell exercise whose weight means per dumbbell or both together, the session is stamped with that meaning, as in the app, and volume counts both bells when it is per dumbbell. Every exercise needs at least one completed set. On a combined day (several routineIds) each exercise is linked to its routine, inferred when not given; sessions of a routine excluded from progression are marked so. leap computes volume, best weights and PR badges as the app does; logging today also raises the remembered working weight. When the plan follows the app's rotation, the output says which sessions of the round the workout did, and the workout that completes a round starts the next one the day after, as the app does. Without a start time, today ends now (starting no earlier than midnight) and other days start at 18:00. No future dates or times: the workout must have ended by now.

Input Schema

NameRequiredDescriptionDefault
dateNoDefault today
nameNoDefault the routine name(s) as the app joins them, else "Freestyle"
noteNo
startNoStart time HH:MM in the user's time zone (the profile's reminder zone, else this machine's)
entriesYes
bodyWeightNoDefault that day's weigh-in, if any
routineIdsNoThe routine(s) this session followed; several make a combined day
durationMinNoDefault 60

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare readOnly=false, destructive=true, openWorld=true; the description carries substantially more, disclosing volume/PR computation, the raise of the remembered working weight, rotation/round advancement behavior, routine-linking on combined days, and progression-excluded marking. It also spells out timing defaults and the future-date prohibition, which go well beyond the structured safety hints.

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?

Purpose is front-loaded in the first sentence and most of the dense detail is warranted by the tool's complexity. However, it is a single sprawling paragraph with deeply nested parentheticals, which hurts scannability for an agent trying to extract a specific rule.

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 complex, heavily nested write tool with no output schema, the description is largely complete, even describing what the output reports about rotation sessions. It does not address what happens if a session already exists for the given date, nor any auth/permission requirements, leaving a gap around the destructiveHint annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75% yet the description meaningfully extends it: it explains how set variants map to fields (drops, clusters with reps as the total, max, per-side left/right, sec with side L then R, cardio min/speed/incline), the profile weight unit and per-dumbbell vs both-bells meaning, and the requirement of at least one completed set. This is real semantics beyond the schema text.

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

Purpose4/5

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

The opening sentence states a specific verb and resource: 'Log a finished workout.' That is clearly distinct from the read-side siblings (read_workout, read_workouts) and from write_update_workout, though the description never explicitly names those alternatives. Purpose is unambiguous even without an explicit sibling contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied throughout (finished sessions only, no future dates, defaults for start time), but there is no explicit statement of when to choose this over write_update_workout or what preconditions apply beyond the timing rule. The agent must infer the boundary between logging a new session and updating one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools