Wellness Project

log_body_metrics

UNIT INPUTS: never convert units yourself. For each canonical field below, pass the user's number exactly as stated when it is already in the canonical unit; when they gave the alternate unit instead, pass the same number unconverted and set the matching companion field so the tool converts once before storage. Omit the companion when the number is already canonical. This overrides any wording that asks you to do the arithmetic.

_lb fields: lb, or kg with input_weight_unit set.
_mi fields: mi, or km with input_distance_unit set.
_in fields: in, or cm with input_length_unit set.
_stated_g fields: g, or oz with input_mass_unit set.
_stated_ml fields: ml, or fl_oz with input_volume_unit set.

Log or update body composition metrics for a given date. Use when the user shares weight, body fat percentage, or any other body composition reading — whether typed manually, copy-pasted from a smart scale app, or described from a photo of a scale display.

PROACTIVE DATA COLLECTION: If the user hasn't shared their data yet, ask them to copy-paste the output from their scale app or upload a photo of the display — this lets you parse all fields at once instead of asking one by one.

INFER — do not ask:

date: default to today; infer from context ("this morning", "yesterday")
derived fields (lean_mass_lb, fat_mass_lb): calculate from weight and body fat % if possible — lean = weight × (1 - bf%/100), fat = weight × bf%/100

The *_pct fields are percentages 0-100. The *_in fields are manual tape measurements, not bioimpedance scale readings.

BMI is not a field here. It is derived automatically at read time from the user's canonical height and their resolved weight for the day -- never ask the user for BMI, and never try to log it.

Every field except date is optional; log any subset. One row per day. Calling this tool twice on the same date updates the existing entry (upsert).

Input Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Date of the measurement. Format: YYYY-MM-DD. Default to today.
`notes`	No	Any context worth noting (e.g. "post-workout", "morning fasted").
`hips_in`	No	Hip circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`chest_in`	No	Chest circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`waist_in`	No	Waist circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`calf_l_in`	No	Left calf circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`calf_r_in`	No	Right calf circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`weight_lb`	No	Body weight in pounds, between 50 and 700. Convert from kilograms if the user spoke in kg (kg x 2.2046). In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`bicep_l_in`	No	Left bicep circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`bicep_r_in`	No	Right bicep circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`thigh_l_in`	No	Left thigh circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`thigh_r_in`	No	Right thigh circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
`fat_mass_lb`	No	Fat mass. Calculate from weight and body fat % if not explicitly stated. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`protein_pct`	No	Protein percentage (0-100).
`body_fat_pct`	No	Body fat percentage (0-100).
`bone_mass_lb`	No	Bone mass. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`lean_mass_lb`	No	Lean (non-fat) mass. Calculate from weight and body fat % if not explicitly stated. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`hydration_pct`	No	Body water/hydration percentage.
`muscle_mass_lb`	No	Skeletal muscle mass. Skeletal muscle tissue specifically, NOT lean_mass_lb, which is total non-fat mass including water, organs and bone. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`input_length_unit`	No	Set to cm when the user gave cm for the _in fields in this object. Omit when they are already in.
`input_weight_unit`	No	Set to kg when the user gave kg for the _lb fields in this object. Omit when they are already lb.
`skeletal_muscle_pct`	No	Skeletal muscle percentage (0-100).
`visceral_fat_rating`	No	Visceral fat rating (scale varies by device, typically 1-59).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Human-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 15, 2026

changedInput schema / properties / weight_lb / description

Previous value: -"Body weight. In lb, or kg with input_weight_unit set. See UNIT INPUTS."New value: +"Body weight in pounds, between 50 and 700. Convert from kilograms if the user spoke in kg (kg x 2.2046). In lb, or kg with input_weight_unit set. See UNIT INPUTS."

Changed23 schema fields changedSep 7, 2026

addedInput schema / properties / bicep_l_in

Added value: +{
+  "description": "Left bicep circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

addedInput schema / properties / bicep_r_in

Added value: +{
+  "description": "Right bicep circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

removedInput schema / properties / bmi

Removed value: -{
-  "description": "Body mass index. Optional — include if the scale or app reports it.",
-  "type": "number"
-}

changedInput schema / properties / body_fat_pct / description

Previous value: -"Body fat percentage (0–100). Optional."New value: +"Body fat percentage (0-100)."

changedInput schema / properties / bone_mass_lb / description

Previous value: -"Bone mass in POUNDS, always. Convert from kg if needed (kg × 2.2046). Optional."New value: +"Bone mass. In lb, or kg with input_weight_unit set. See UNIT INPUTS."

addedInput schema / properties / calf_l_in

Added value: +{
+  "description": "Left calf circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

addedInput schema / properties / calf_r_in

Added value: +{
+  "description": "Right calf circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

addedInput schema / properties / chest_in

Added value: +{
+  "description": "Chest circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

changedInput schema / properties / fat_mass_lb / description

Previous value: -"Fat mass in POUNDS, always. Convert from kg if needed (kg × 2.2046). Optional — calculate from weight and body fat % if not explicitly stated."New value: +"Fat mass. Calculate from weight and body fat % if not explicitly stated. In lb, or kg with input_weight_unit set. See UNIT INPUTS."

addedInput schema / properties / hips_in

Added value: +{
+  "description": "Hip circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

changedInput schema / properties / hydration_pct / description

Previous value: -"Body water/hydration percentage. Optional."New value: +"Body water/hydration percentage."

addedInput schema / properties / input_length_unit

Added value: +{
+  "description": "Set to cm when the user gave cm for the _in fields in this object. Omit when they are already in.",
+  "enum": [
+    "in",
+    "cm"
+  ],
+  "type": "string"
+}

addedInput schema / properties / input_weight_unit

Added value: +{
+  "description": "Set to kg when the user gave kg for the _lb fields in this object. Omit when they are already lb.",
+  "enum": [
+    "lb",
+    "kg"
+  ],
+  "type": "string"
+}

changedInput schema / properties / lean_mass_lb / description

Previous value: -"Lean (non-fat) mass in POUNDS, always. Convert from kg if needed (kg × 2.2046). Optional — calculate from weight and body fat % if not explicitly stated."New value: +"Lean (non-fat) mass. Calculate from weight and body fat % if not explicitly stated. In lb, or kg with input_weight_unit set. See UNIT INPUTS."

addedInput schema / properties / muscle_mass_lb

Added value: +{
+  "description": "Skeletal muscle mass. Skeletal muscle tissue specifically, NOT lean_mass_lb, which is total non-fat mass including water, organs and bone. In lb, or kg with input_weight_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

changedInput schema / properties / notes / description

Previous value: -"Any context worth noting (e.g. \"post-workout\", \"morning fasted\"). Optional."New value: +"Any context worth noting (e.g. \"post-workout\", \"morning fasted\")."

addedInput schema / properties / protein_pct

Added value: +{
+  "description": "Protein percentage (0-100).",
+  "type": "number"
+}

addedInput schema / properties / skeletal_muscle_pct

Added value: +{
+  "description": "Skeletal muscle percentage (0-100).",
+  "type": "number"
+}

addedInput schema / properties / thigh_l_in

Added value: +{
+  "description": "Left thigh circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

addedInput schema / properties / thigh_r_in

Added value: +{
+  "description": "Right thigh circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

changedInput schema / properties / visceral_fat_rating / description

Previous value: -"Visceral fat rating (scale varies by device, typically 1–59). Optional."New value: +"Visceral fat rating (scale varies by device, typically 1-59)."

addedInput schema / properties / waist_in

Added value: +{
+  "description": "Waist circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

changedInput schema / properties / weight_lb / description

Previous value: -"Body weight in POUNDS, always — regardless of the user’s display unit. If the user gave kg, convert to pounds before calling (kg × 2.2046). Optional."New value: +"Body weight. In lb, or kg with input_weight_unit set. See UNIT INPUTS."

Changed4 schema fields changedAug 4, 2026

changedInput schema / properties / bone_mass_lb / description

Previous value: -"Bone mass in pounds. Optional."New value: +"Bone mass in POUNDS, always. Convert from kg if needed (kg × 2.2046). Optional."

changedInput schema / properties / fat_mass_lb / description

Previous value: -"Fat mass in pounds. Optional — calculate from weight and body fat % if not explicitly stated."New value: +"Fat mass in POUNDS, always. Convert from kg if needed (kg × 2.2046). Optional — calculate from weight and body fat % if not explicitly stated."

changedInput schema / properties / lean_mass_lb / description

Previous value: -"Lean (non-fat) mass in pounds. Optional — calculate from weight and body fat % if not explicitly stated."New value: +"Lean (non-fat) mass in POUNDS, always. Convert from kg if needed (kg × 2.2046). Optional — calculate from weight and body fat % if not explicitly stated."

changedInput schema / properties / weight_lb / description

Previous value: -"Body weight in pounds. Optional."New value: +"Body weight in POUNDS, always — regardless of the user’s display unit. If the user gave kg, convert to pounds before calling (kg × 2.2046). Optional."

First observedAug 2, 2026

TDQS

A4/5.0

Behavior1/5

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

The description contains rich behavioral disclosure: unit conversion companion fields, derived lean/fat mass calculation, optional fields, proactive data collection, and upsert behavior. However, annotations declare idempotentHint false, while the description explicitly says 'Calling this tool twice on the same date updates the existing entry (upsert)' — an idempotent upsert behavior that contradicts the annotation. Per the rubric, description contradicting annotations must score 1.

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 long but very well structured: UNIT INPUTS, PROACTIVE DATA COLLECTION, INFER, and exclusion rules are all labeled and front-loaded. Vital unit-handling rules appear first because getting them wrong corrupts stored data. Every block earns its place, and the layout makes the dense content scannable.

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 23-parameter tool with unit pitfalls, derivation logic, and upsert semantics, the description is nearly exhaustive. It covers when to use the tool, how to infer dates, how to handle all supported unit cases, which fields to derive, which fields are optional, how duplicate calls behave, and what not to log. The output schema exists, so omitting return-value explanation is acceptable.

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?

Schema coverage is 100%, so baseline is 3, and the description adds a great deal of added meaning: exact rules for passing numbers unconverted and setting companion unit fields, formulas for lean_mass_lb and fat_mass_lb, the distinction between muscle_mass_lb and lean_mass_lb, and the clarification that *_in fields are manual tape measurements while *_pct fields are percentages. This is substantive semantic guidance beyond the schema.

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 states a specific action on a specific resource: 'Log or update body composition metrics for a given date.' It names the exact trigger condition with concrete examples like weight, body fat percentage, typed manual input, copy-pasted scale output, or scale-display photos. This makes it clearly distinguishable from sibling read tools like list_body_metrics and show_body_composition.

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

Usage Guidelines4/5

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

The description clearly says when to use the tool: whenever the user shares body composition data. It also gives exclusions such as 'BMI is not a field here... never ask the user for BMI, and never try to log it' and gives proactive collection guidance. It does not explicitly name alternative sibling tools or explicit when-not conditions relative to list_body_metrics/show_body_composition, so it falls just short of a 5.

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

All Wellness Project 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.

log_body_metrics

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources