Skip to main content
Glama
Sign In

AIm Workout Journal

by com.aim-journal
OverviewDiscussionsAdmin

Record a body measurement

log_body_metric
DestructiveIdempotent

Record the user's body weight, body-fat % or circumferences for one day, when the user states a current measurement. Training goes to log_session, and measurements are read back with get_body_metrics. The app's weight tile and charts and the coaching context read these entries, not the profile's bodyweight field. One entry per date, and recording the same date again ADDS to it: fields left out keep their stored value, new measurements or custom_fields keys join the existing ones, and a repeated key or field is overwritten, which is how a wrong number is corrected. A field sent as null is cleared. Returns the whole stored entry for that day. There is no delete.

Input Schema

NameRequiredDescriptionDefault
metricYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / metric / properties / body_fat_pct / anyOf
      Previous value: -[
-  {
-    "maximum": 100,
-    "minimum": 0,
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 75,
+    "minimum": 2,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / metric / properties / body_fat_pct / description
      Previous value: -"Body-fat percentage, 0 to 100."New value: +"Body-fat percentage, 2 to 75."
    • changedInput schema / properties / metric / properties / bodyweight_kg / anyOf
      Previous value: -[
-  {
-    "minimum": 0,
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 500,
+    "minimum": 20,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / metric / properties / bodyweight_kg / description
      Previous value: -"Body weight in kilograms (1 lb = 0.4536 kg)."New value: +"Body weight in kilograms, 20 to 500 (1 lb = 0.4536 kg)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / metric / properties / bodyweight_kg / description
      Previous value: -"Body weight in kilograms. Convert pounds first (1 lb = 0.4536 kg)."New value: +"Body weight in kilograms (1 lb = 0.4536 kg)."
    • changedInput schema / properties / metric / properties / id / description
      Previous 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."New value: +"Absent for a measurement the user states in conversation: that entry is 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."
  3. Changed9 schema fields changed
    • addedInput schema / properties / metric / properties / athlete_id / description
      Added value: +"Ignored when recording: every entry belongs to the signed-in user."
    • addedInput schema / properties / metric / properties / body_fat_pct / description
      Added value: +"Body-fat percentage, 0 to 100."
    • addedInput schema / properties / metric / properties / bodyweight_kg / description
      Added value: +"Body weight in kilograms. Convert pounds first (1 lb = 0.4536 kg)."
    • addedInput schema / properties / metric / 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 / metric / 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 / metric / 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 / metric / 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 / metric / properties / notes / description
      Added value: +"Context the user gave with the number (fasted, evening, after travel)."
    • addedInput schema / properties / metric / properties / source / description
      Added value: +"Where the number came from, free text: `scale`, `tape`, `dexa`, `smart_scale`"
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare write/destructive/idempotent, and the description goes well past them: it explains the upsert merge rules (omitted fields keep stored values, new keys join, repeated keys overwrite), that null clears a field, that there is no delete, and that the whole stored entry is returned. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then routing, then merge semantics. Every clause carries operational meaning (one entry per date, overwrite-as-correction, no delete) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested-object write tool with an output schema present, the definition covers trigger, alternatives, merge/overwrite behavior, null-clearing and the absence of delete. Nothing an agent needs to call it safely is missing; return shape is delegated to the output schema.

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?

The nested `metric` schema has rich per-field descriptions, and the description still adds merge semantics that the schema only hints at (omitted fields retained, new measurements/custom_fields keys join, null clears, repeated key overwrites). It doesn't restate units or ranges, which the schema already covers, so it stops short of a 5.

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 and resource set ('Record the user's body weight, body-fat % or circumferences for one day') and immediately contrasts with the siblings log_session (training) and get_body_metrics (read-back). An agent can distinguish it from every other logging tool without opening a schema.

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 an explicit trigger condition ('when the user states a current measurement'), names the alternatives for adjacent intents (log_session, get_body_metrics), and adds a routing caveat: the app's weight tile, charts and coaching context read these entries, not the profile's bodyweight field.

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 toolsInspect
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.

Resources