Skip to main content
Glama
turnnoblindeye

Wellness Project MCP

log_body_metrics

Turn weight and body composition readings from smart scale apps, photos, or manual entry into a dated log entry; re-running for the same date updates it.

Instructions

UNIT INPUTS: never convert units yourself. Pass the user's number for a _lb / _mi / _in field exactly as stated, and when they gave kg / km / cm set input_weight_unit / input_distance_unit / input_length_unit in that same object. Omit the companion when the number is already lb / mi / in. The tool converts once before storage, so this overrides any wording that asks you to do the arithmetic.

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
NameRequiredDescriptionDefault
dateYesDate of the measurement. Format: YYYY-MM-DD. Default to today.
notesNoAny context worth noting (e.g. "post-workout", "morning fasted").
hips_inNoHip circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
chest_inNoChest circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
waist_inNoWaist circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
calf_l_inNoLeft calf circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
calf_r_inNoRight calf circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
weight_lbNoBody weight. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
bicep_l_inNoLeft bicep circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
bicep_r_inNoRight bicep circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
thigh_l_inNoLeft thigh circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
thigh_r_inNoRight thigh circumference. In in, or cm with input_length_unit set. See UNIT INPUTS.
fat_mass_lbNoFat mass. Calculate from weight and body fat % if not explicitly stated. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
protein_pctNoProtein percentage (0-100).
body_fat_pctNoBody fat percentage (0-100).
bone_mass_lbNoBone mass. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
lean_mass_lbNoLean (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_pctNoBody water/hydration percentage.
muscle_mass_lbNoSkeletal 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_unitNoSet to cm when the user gave cm for the _in fields in this object. Omit when they are already in.
input_weight_unitNoSet to kg when the user gave kg for the _lb fields in this object. Omit when they are already lb.
skeletal_muscle_pctNoSkeletal muscle percentage (0-100).
visceral_fat_ratingNoVisceral fat rating (scale varies by device, typically 1-59).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesHuman-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.2.1

TDQS

A4.5/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: one row per day, calling twice on the same date is an upsert, all fields except date are optional, and the tool converts units once before storage. These are critical runtime behaviors an agent needs to know and are not present in the annotations.

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 but justified given 23 parameters and complex unit/derivation rules. It is logically sectioned, though not perfectly front-loaded: the purpose statement appears only after an initial dense unit-input paragraph.

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

Completeness4/5

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

For a high-complexity tool, the description covers purpose, usage, units, inference rules, upsert behavior, and exclusions like BMI. An output schema exists, so return-value details are not necessary. The minor input_distance_unit inaccuracy prevents a perfect score.

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 is 100%, but the description greatly enhances parameter meaning by explaining unit-input conventions, derived-field formulas, percentage ranges, and the distinction between muscle mass and lean mass. It loses a point because it references input_distance_unit, which does not exist in this tool's schema, creating potential confusion.

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 clearly states the tool's function: 'Log or update body composition metrics for a given date.' It names the exact resource and action, and differentiates itself from sibling read/list tools by explicitly describing when the user shares a body composition reading.

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?

It gives strong when-to-use guidance: weight, body fat percentage, or other composition readings from manual entry, smart scale apps, or photos. It also provides important when-not behavior, such as never asking for BMI. However, it does not explicitly name alternative tools like log_wearable or list_body_metrics for exclusions.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/turnnoblindeye/wellness-project-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server