Skip to main content
Glama

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

TableJSON Schema
NameRequiredDescriptionDefault
metricYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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."
  2. 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`"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it explains the upsert/merge semantics (omitted fields keep stored values, new measurements/custom_fields keys join existing ones, repeated keys are overwritten), null clearing, that no delete exists, and that the whole stored entry is returned. This makes the idempotentHint=true and destructiveHint=true annotations interpretable rather than cryptic.

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?

Front-loaded with the core action, then routing, then merge semantics. Dense but nearly every sentence carries information an agent needs; the 'no delete' note and the profile-bodyweight remark are worth their space. Slightly long for a single-parameter tool.

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 mutation with an output schema, the description covers the operation, its trigger, its siblings, its merge/correction semantics, and the clearing behavior. Nothing needed to call it correctly is missing.

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 coverage reads 0% at the top level, but the nested metric object has per-field descriptions; the description still adds meaning by summarizing which metric families are accepted (weight, body-fat %, circumferences, custom fields) and by describing merge/overwrite behavior that no schema field states. It doesn't cover id/source semantics in the description, but the schema does.

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?

Names a specific verb and resource (record body weight/body-fat %/circumferences for one day) and explicitly distinguishes itself from siblings: training goes to log_session and reads go to get_body_metrics. It even clarifies that the app's weight tile and coaching context read these entries rather than the profile bodyweight field, removing the most likely confusion.

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?

States the trigger condition ('when the user states a current measurement') and routes the two adjacent cases to their correct tools (log_session for training, get_body_metrics for reading back). The one-entry-per-date merge rule is spelled out so the agent knows a second call for the same date is additive rather than a duplicate.

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