AIm

Record a body measurement

log_body_metric

Record a daily body metric (weight, body-fat %, circumferences), merging into that day's entry. Overwrite a wrong number by sending the corrected value.

Instructions

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 changedv1.2.2Sep 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 observedv1.2.1Sep 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only convey readOnlyHint=false and destructiveHint=false; the description carries the real behavioral load, and it does so richly: same-date recording ADDS to the entry, omitted fields keep their stored value, repeated keys are overwritten ("how a wrong number is corrected"), null clears a field, and "There is no delete." These merge semantics are exactly what an agent must know and are not derivable from the annotations. No contradiction — the write intent matches readOnlyHint=false and the overwrite/no-delete behavior is consistent with destructiveHint=false.

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?

The description is long (~120 words) but every sentence carries a distinct, load-bearing fact — purpose, routing, data-flow consumer, merge semantics, null-clearing, return value, no-delete. It is front-loaded with purpose and routing before the dense behavioral rules. It forfeits a 5 only because it is a single unbroken paragraph; the density is justified by the genuinely complex merge behavior.

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, merge-semantics tool with an output schema present, the description covers everything an agent needs to call it correctly: when to use it, what it returns ("Returns the whole stored entry for that day"), the additive overwrite behavior, null-clearing, and the no-delete constraint. The return value is stated even though an output schema exists, and the id semantics are cross-referenced to import_document. Nothing essential 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?

The top-level `metric` parameter has no schema description (0% coverage), so the description must compensate, and it does by adding the behavioral layer absent from the schema: the date-keying rule, the merge-on-repeated-date behavior, null-clearing, and the id-vs-date distinction tied to import_document. The nested properties are already well described in the schema (units, ranges, field meanings), so the description need not repeat them; it adds genuine semantic value on top rather than restating fields.

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?

Opens with a specific verb+resource: "Record the user's body weight, body-fat % or circumferences for one day." It then explicitly names the siblings it is not — "training goes to log_session, and reading measurements back is get_body_metrics" — so an agent can disambiguate without inspecting other definitions. The scope (one day, keyed by date) is stated up front.

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 — "Use it whenever the user states a current measurement" — and names the alternatives with their routing conditions: log_session for training, get_body_metrics for reading back, and import_document for id-copied entries. The when-not is fully specified and matches the sibling names, leaving nothing to inference.

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