AIm Workout Journal

Record a body measurement

log_body_metric

DestructiveIdempotent

Record the user's body weight, body-fat % or circumferences for one day. Use it whenever the user states a current measurement; training goes to log_session, and reading measurements back is 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: send only what the user just told you. Fields you leave 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. Send a field as null to clear it. Returns the whole stored entry for that day. There is no delete.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`metric`	Yes

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 / 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`"

First observedSep 6, 2026

TDQS

A5/5.0

Behavior5/5

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

Goes well beyond the idempotentHint and destructiveHint annotations by explaining one-entry-per-date merging, overwrite-on-repeat, null-to-clear behavior, no-delete policy, and the full-entry return value. This gives the agent a precise model of the mutation semantics.

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?

The description is dense but every sentence earns its place, front-loading the core purpose and then systematically covering usage, merge behavior, correction, clearing, and return value. No filler or repetition of schema details.

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 tool with a nested parameter object and subtle update semantics, the description covers when to use it, how it differs from siblings, what the merge/overwrite/null behaviors are, how IDs relate to import_document, and what the response is. 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.

Parameters5/5

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

Adds critical merge semantics that the schema alone does not convey: omitted fields keep their stored values, new keys join existing ones, repeated keys overwrite, and null clears a field. It also tells the agent to send only what the user just stated, which is essential for correct partial updates.

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: 'Record the user's body weight, body-fat % or circumferences for one day.' It also names the sibling alternatives (log_session, get_body_metrics) to prevent 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?

Explicitly instructs when to use it ('whenever the user states a current measurement') and where other operations belong ('training goes to log_session, reading measurements back is get_body_metrics'). Also clarifies that these entries feed the app's weight tile and coaching context, not the profile 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 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.