AIm Workout Journal

Review a program draft

review_program_draft

Read-only

Server-side checklist for a DRAFT training program. Call it with the same WorkoutDocument you intend to import BEFORE presenting the draft to the user: it verifies day references resolve, every exercise is identifiable, rep ranges make sense, and — in 'coached' mode — that each exercise has a starting weight (or calibration note), matches the user's equipment and respects session length / weekly days.

Pass program_mode='preserve' when the document is the user's OWN program brought in from a file. The same structural errors are refused, but a missing weight is accepted as a fact about their program, and an equipment or schedule mismatch comes back as a warning to show them rather than a violation to fix. Use the same mode you will pass to import_document.

Returns {ok, mode, violations, warnings, unresolved, notes}. unresolved lists fields the file never stated — ask about those; never fill them in. Saves nothing, and creates nothing: reviewing somebody's file is not the start of a coaching relationship.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`document`	Yes
`program_mode`	No		coached

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedSep 15, 2026

addedInput schema / properties / document / properties / body_metrics / items / properties / athlete_id / description
```
Added value: +"Ignored when recording: every entry belongs to the signed-in user."
```
addedInput schema / properties / document / properties / body_metrics / items / properties / body_fat_pct / description
```
Added value: +"Body-fat percentage, 0 to 100."
```
addedInput schema / properties / document / properties / body_metrics / items / properties / bodyweight_kg / description
```
Added value: +"Body weight in kilograms. Convert pounds first (1 lb = 0.4536 kg)."
```

addedInput schema / properties / document / properties / body_metrics / items / properties / custom_fields / description

Added value: +"Anything worth keeping that has no field above, such as `resting_hr`. Stored and exported, not displayed."

addedInput schema / properties / document / properties / body_metrics / items / properties / date / description

Added value: +"Day the measurement was taken, YYYY-MM-DD in the user's own calendar. Without an id there is one entry per day: recording the same date again adds to that day's entry, overwriting only the fields and keys you send."

addedInput schema / properties / document / properties / body_metrics / items / properties / id / description

Added value: +"Leave empty when recording a measurement the user gives you: the entry is then keyed by its date. An id marks an entry copied from a source document (an export, a spreadsheet); import_document manages those, and recording the same id twice fails."

addedInput schema / properties / document / properties / body_metrics / items / properties / measurements / description

Added value: +"Circumferences in centimetres, keyed `<site>_cm`. The app shows `chest_cm`, `arm_cm`, `waist_cm` and `thigh_cm`; any other site is stored but not displayed."

addedInput schema / properties / document / properties / body_metrics / items / properties / notes / description
```
Added value: +"Context the user gave with the number (fasted, evening, after travel)."
```
addedInput schema / properties / document / properties / body_metrics / items / properties / source / description
```
Added value: +"Where the number came from, free text: `scale`, `tape`, `dexa`, `smart_scale`"
```

Changed2 schema fields changedSep 10, 2026

added

Input schema / properties / document / properties / sessions / items / properties / entries / items / properties / sets / items / properties / set_id

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 128,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The client's own stable id for this set, if it has one. Only the AIm app sends this: it lets a later correction be traced to the set that moved, because set_number is renumbered when a set is removed. Never invent one — omit it."
+}

addedInput schema / properties / program_mode

Added value: +{
+  "default": "coached",
+  "enum": [
+    "coached",
+    "preserve"
+  ],
+  "type": "string"
+}

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description reinforces and extends this: 'Saves nothing, and creates nothing: reviewing somebody's file is not the start of a coaching relationship.' It goes beyond the annotations by disclosing the exact return contract ({ok, mode, violations, warnings, unresolved, notes}) and the meaning of `unresolved` ('lists fields the file never stated — ask about those; never fill them in'). This is rich behavioral context that the readOnlyHint alone would not convey.

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?

Three dense paragraphs with the purpose and timing front-loaded, followed by the mode differentiation and the return contract. Every sentence carries information — the mode explanation is lengthy but necessary given the two divergent behaviors. Minor redundancy: 'Saves nothing, and creates nothing' restates readOnlyHint, but the coaching-relationship framing adds value. No wasted words for a tool of this complexity.

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?

The description covers the full decision surface: when to call, what it validates (day references, exercise identifiability, rep ranges, weight/equipment/schedule in coached mode), the mode-specific behavior, the return contract, and the semantic of `unresolved`. With a rich input schema and an output contract disclosed inline, nothing an agent needs to call it correctly is missing. Only the document's internal structure is left to the schema, which is appropriate.

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?

Schema description coverage is 0%, so the description must compensate — and it does substantially for program_mode, explaining both enum values' behavioral consequences (coached enforces starting weight/equipment/schedule; preserve downgrades mismatches to warnings). The document parameter is handled by reference ('the same WorkoutDocument you intend to import'), tying it to import_document's input. It doesn't enumerate the document structure, but the schema already carries that detail, so the pointer is sufficient.

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?

The description opens with a specific verb+resource: 'Server-side checklist for a DRAFT training program' — a validation/verification tool, clearly distinct from its siblings. It explicitly differentiates itself from import_document ('Use the same mode you will pass to import_document'), so an agent can tell them apart without opening the schema. The name, title, and description are mutually consistent.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance: 'Call it with the same WorkoutDocument you intend to import BEFORE presenting the draft to the user' — this sets the sequencing against import_document. It further explains the two modes ('coached' default vs 'preserve' for user's own file), telling the agent exactly when each applies and to mirror the mode passed to import_document. Nothing is left to inference.

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

All AIm Workout Journal tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.